From: Jeremy Fitzhardinge <jeremy@goop.org>
To: "Nakajima, Jun" <jun.nakajima@intel.com>
Cc: Andi Kleen <ak@suse.de>, Zachary Amsden <zach@vmware.com>,
Rusty Russell <rusty@rustcorp.com.au>,
Avi Kivity <avi@qumranet.com>,
Glauber de Oliveira Costa <glommer@gmail.com>,
Anthony Liguori <anthony@codemonkey.ws>,
Virtualization Mailing List <virtualization@lists.osdl.org>,
Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH RFC] paravirt_ops: refactor struct paravirt_ops into smaller pv_*_ops
Date: Sat, 29 Sep 2007 10:01:18 -0700 [thread overview]
Message-ID: <46FE84DE.4090705@goop.org> (raw)
In-Reply-To: <97D612E30E1F88419025B06CB4CF1BE1039B6DDB@scsmsx412.amr.corp.intel.com>
Nakajima, Jun wrote:
> To me such atomicity is provided by the "sti" instruction (i.e. the
> processor begins responding to external, maskable interrupts _after_ the
> next instruction is executed), and there is nothing special with that
> combination "sti; hlt" (you can also have like "sti; ret", for example).
>
Sure, but there's no particular value in "sti; ret". While the sti mask
window works everywhere, its only cases like "sti; hlt" where it's
needed to avoid a race condition.
> So if you define a PV ops like STI(next_instruction), "safe_halt" for
> the native should be defined as STI("hlt"), and inlined as "sti; hlt".
>
That's only meaningful if the pv_op is implemented directly in x86
instructions - ie, the native (or almost native) case.
> If it's hard or we don't need to expose the semantics of "sti" other
> than that, I think it's okay to have a PV operation for safe_halt.
>
Yeah, the general form would be hard to support for a hypervisor. Xen,
for example, has an "atomically enable events and block" operation, but
no other "atomically enable events and do X" operations.
J
prev parent reply other threads:[~2007-09-29 17:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-28 18:10 [PATCH RFC] paravirt_ops: refactor struct paravirt_ops into smaller pv_*_ops Jeremy Fitzhardinge
2007-09-28 18:10 ` Jeremy Fitzhardinge
2007-09-28 18:39 ` Zachary Amsden
2007-09-28 18:49 ` Jeremy Fitzhardinge
2007-09-28 19:02 ` Zachary Amsden
2007-09-28 23:25 ` Nakajima, Jun
2007-09-28 23:25 ` Nakajima, Jun
2007-09-28 23:36 ` Jeremy Fitzhardinge
2007-09-29 0:19 ` Nakajima, Jun
2007-09-29 0:40 ` Jeremy Fitzhardinge
2007-09-29 16:55 ` Nakajima, Jun
2007-09-29 17:01 ` Jeremy Fitzhardinge [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=46FE84DE.4090705@goop.org \
--to=jeremy@goop.org \
--cc=ak@suse.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=anthony@codemonkey.ws \
--cc=avi@qumranet.com \
--cc=glommer@gmail.com \
--cc=jun.nakajima@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rusty@rustcorp.com.au \
--cc=tglx@linutronix.de \
--cc=virtualization@lists.osdl.org \
--cc=zach@vmware.com \
/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.