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.