On 2012-02-07 16:25, Simon wrote: > We're building a virtual windows 7 x64 model on top of a custom Linux OS. > We're currently using 2.6.38.8 kernel. > I was rather attracted to the new kvm-apic/qemu-kvm merge you've currently > made available, as this may hold the answer to a stubborn problem; > every time we load or attempt to create a windows 7 image while > our RTAI(real time) base is running, at an early stage of loading > windows the real time breaks and stops dead. > > We suspect this is due to APIC conflicts between RTAI and Qemu-kvm. > > I've read with interest your internal debate on making kvm-apic options > available, and I wonder if these now exist and if so, what they are > (the online help may not have kept pace). > Note that these are 64-bit OS's. With older kernels and 0.13.0 > with 32 bit XP, we didn't have this problem. That's Russian roulette. You can't simply use KVM (or any other virtualization subsystem) on an I-pipe-patched host kernel. See [1] for the requirements on I-pipe (will be contained a bit differently in upcoming 3.x patches for x86) and [2] for the real-time extension on top. We implemented it for Xenomai, but RTAI should be patchable as well - in principle. Note that there is potentially a FPU-related guest corruption with these patches remaining, but I wasn't able to reproduce it yet. May depend on host CPU features. Just to clarify: this is not really a topic of KVM or upstream Linux - or even QEMU. The I-pipe patch changes the semantics of low-level interrupt masking in Linux and opens new context switching points. Thus, it is responsible for making the KVM subsystem aware of this and for coordination with the real-time extension. Jan [1] http://thread.gmane.org/gmane.linux.kernel.adeos.general/1898 [2] http://git.xenomai.org/?p=xenomai-2.6.git;a=commitdiff;h=35505fe10c0dae3d1eab8a409b978d338b84b89e -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
