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

[Gleb Natapov]

On Wed, Dec 02, 2009 at 01:33:11PM +0100, Jan Kiszka wrote:
> Gleb Natapov wrote:
> > 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.
> > 
> 
> Upstream could still easily deny in-kernel irqchip support if the host
> kvm is not recent enough. qemu-kvm currently has a different policy /wrt
> old kvm modules, so we may work around the mp_state and vcpu_events
> issues there (just cleaner than so far).
> 
There is no kernel (released or not) that has the bug fixed. So you say
lets always disable everything that this patchset adds?

--
                        Gleb.