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: Thu, 3 Dec 2009 09:33: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.
> 
Actually, thinking about it some more, our problem with mp_state comes
from the way we try to treat it as part of a vcpu state, but in fact
nmi_pending/sipi_vector/mp_state are all part of apic state. So I doubt
that the correct solution lays in the kernel. We should remove mp_state
syncing from put/get cpu state and move it into apic state management
code. To not break "info cpus" halt state reporting we should get apic
state in addition to vcpu state on that monitor command.

--
                        Gleb.




reply via email to

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