From: Jan Kiszka <jan.kiszka@siemens.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
Glauber Costa <glommer@gmail.com>,
Glauber Costa <glommer@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"agraf@suse.de" <agraf@suse.de>,
"avi@redhat.com" <avi@redhat.com>
Subject: [Qemu-devel] Re: [PATCH v2 05/11] tell kernel about all registers instead of just mp_state
Date: Wed, 02 Dec 2009 13:35:16 +0100 [thread overview]
Message-ID: <4B165F04.8090000@siemens.com> (raw)
In-Reply-To: <20091202122653.GD9537@redhat.com>
Gleb Natapov wrote:
> On Wed, Dec 02, 2009 at 01:10:22PM +0100, Jan Kiszka wrote:
>> Glauber Costa wrote:
>>>>> +{
>>>>> + if (kvm_enabled()) {
>>>> Is this ever called or intended to be called when kvm is disabled?
>>>>
>>>>> + kvm_cpu_flush_state(env);
>>>>> + }
>>> I don't think so. But this is here for consistency with its synchronize brother.
>> Ack. As soon as someone starts to use this generic service outside code
>> that is only built under CONFIG_KVM or called when kvm is enabled,
>> things will break.
>>
> We can add the check when adding first such user. Code outside
> CONFIG_KVM can't use this since the function is in kvm.h header.
> I don't have really strong opinion about that. I personally use
> kvm_enabled() as a hint that code is generic for kvm and non-kvm
> case when reading code.
It's the same case as with cpu_synchronize_state, just that the latter
is already used outside kvm code. Both services logically belong into a
different header but are in kvm.h for simplicity reasons.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2009-12-02 12:35 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 [this message]
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
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=4B165F04.8090000@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=agraf@suse.de \
--cc=aliguori@us.ibm.com \
--cc=avi@redhat.com \
--cc=gleb@redhat.com \
--cc=glommer@gmail.com \
--cc=glommer@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).