[Qemu-devel] Re: [PATCH v2 0/11]

[Gleb Natapov]

On Wed, Dec 02, 2009 at 01:25:39PM +0100, Jan Kiszka wrote:
> 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
> 
I don't think we can realistically fix all older kernels. Anyway if the
workaround for the bug will not be done in qemu we need to fix it in kernel
ASAP and start to propagate it to stable releases.

--
                        Gleb.