qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gleb Natapov
Subject: [Qemu-devel] Re: [PATCH v2 0/11]
Date: Wed, 2 Dec 2009 14:22:50 +0200

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.

--
                        Gleb.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]