From: Gleb Natapov <gleb@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: qemu-devel@nongnu.org, Glauber Costa <glommer@redhat.com>,
avi@redhat.com, agraf@suse.de, aliguori@us.ibm.com
Subject: [Qemu-devel] Re: [PATCH v2 0/11]
Date: Thu, 3 Dec 2009 09:33:50 +0200 [thread overview]
Message-ID: <20091203073350.GD20102@redhat.com> (raw)
In-Reply-To: <4B1657C0.20104@siemens.com>
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.
prev parent reply other threads:[~2009-12-03 7:34 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-01 12:51 [Qemu-devel] [PATCH v2 0/11] Glauber Costa
2009-12-01 12:51 ` [Qemu-devel] [PATCH v2 01/11] Don't mess with halted state Glauber Costa
2009-12-01 12:51 ` [Qemu-devel] [PATCH v2 02/11] store thread-specific env information Glauber Costa
2009-12-01 12:51 ` [Qemu-devel] [PATCH v2 03/11] update halted state on mp_state sync Glauber Costa
2009-12-01 12:51 ` [Qemu-devel] [PATCH v2 04/11] qemu_flush_work for remote vcpu execution Glauber Costa
2009-12-01 12:51 ` [Qemu-devel] [PATCH v2 05/11] tell kernel about all registers instead of just mp_state Glauber Costa
2009-12-01 12:51 ` [Qemu-devel] [PATCH v2 06/11] flush state in migration post_load Glauber Costa
2009-12-01 12:51 ` [Qemu-devel] [PATCH v2 07/11] Don't call kvm cpu reset on initialization Glauber Costa
2009-12-01 12:51 ` [Qemu-devel] [PATCH v2 08/11] use cpu_kick instead of direct signalling Glauber Costa
2009-12-01 12:51 ` [Qemu-devel] [PATCH v2 09/11] Use per-cpu reset handlers Glauber Costa
2009-12-01 12:51 ` [Qemu-devel] [PATCH v2 10/11] Use __thread where available Glauber Costa
2009-12-01 12:51 ` [Qemu-devel] [PATCH v2 11/11] remove smp restriction from kvm Glauber Costa
2009-12-02 10:48 ` [Qemu-devel] [PATCH v2 05/11] tell kernel about all registers instead of just mp_state Gleb Natapov
2009-12-02 11:22 ` Glauber Costa
2009-12-02 12:10 ` [Qemu-devel] " Jan Kiszka
2009-12-02 12:26 ` Gleb Natapov
2009-12-02 12:35 ` Jan Kiszka
2009-12-02 13:27 ` [Qemu-devel] [PATCH v2 04/11] qemu_flush_work for remote vcpu execution Marcelo Tosatti
2009-12-02 13:41 ` Glauber Costa
2009-12-02 13:54 ` Marcelo Tosatti
2009-12-02 14:01 ` Glauber Costa
2009-12-02 10:59 ` [Qemu-devel] [PATCH v2 0/11] Gleb Natapov
2009-12-02 12:00 ` Glauber Costa
2009-12-02 12:04 ` [Qemu-devel] " Jan Kiszka
2009-12-02 12:22 ` Gleb Natapov
2009-12-02 12:25 ` Jan Kiszka
2009-12-02 12:30 ` Gleb Natapov
2009-12-02 12:33 ` Jan Kiszka
2009-12-02 12:49 ` Gleb Natapov
2009-12-03 7:33 ` Gleb Natapov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091203073350.GD20102@redhat.com \
--to=gleb@redhat.com \
--cc=agraf@suse.de \
--cc=aliguori@us.ibm.com \
--cc=avi@redhat.com \
--cc=glommer@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.