Gleb Natapov wrote: > On Wed, Dec 02, 2009 at 01:04:16PM +0100, Jan Kiszka wrote: >> Gleb Natapov wrote: >>> On Tue, Dec 01, 2009 at 10:51:26AM -0200, Glauber Costa wrote: >>>> This is a repost of the -smp series. Note that it depends on >>>> irqchip-in-kernel, >>>> that is already in staging. Also, you'll have to enable the io-thread, for >>>> the time >>>> being. >>>> >>>> >From the last version, main change is that I am not calling queue_work >>>> >automatically >>>> from vcpu ioctls. queue_work is only used currently for the gdb stub. >>>> >>>> All other uses were by-passed by the new qemu_register_vcpu_reset(), since >>>> most >>>> of it uses (all racy) came from the reset handlers. >>>> >>> Looks good to me except one thing. I don't see how you are addressing >>> the problem fixed by commit b8a7857071b477b28d3055e33ff0298fc91f329a >>> in qemu-kvm. The problem is that mp_state can change in kernel between >>> call to kvm_cpu_synchronize_state() and vcpu re-entry. In this case old >>> mp_state will overwrite new one. >> + nmi_pending >> + sipi_vector >> >> These things need to be fixed at kernel level as discussed recently: >> Asynchronous changes done by in-kernel subsystems need to be queued and >> replayed with a higher priority than user space changes. User space need >> to stop the vm if it does not want to be overruled. >> > Long term yes. Short term qemu need to work with existing kernels.
Avi's answer was different [1]. Jan [1] http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/43288 -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux