From: Zachary Amsden <zach@vmware.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andi Kleen <ak@suse.de>, Andrew Morton <akpm@osdl.org>,
virtualization@lists.osdl.org, Chris Wright <chrisw@sous-sol.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Arjan van de Ven <arjan@infradead.org>
Subject: Re: [PATCH] paravirt.h
Date: Tue, 22 Aug 2006 19:12:11 -0700 [thread overview]
Message-ID: <44EBB97B.9030707@vmware.com> (raw)
In-Reply-To: <1156298131.12015.42.camel@localhost.localdomain>
Rusty Russell wrote:
> On Tue, 2006-08-22 at 15:02 -0700, Zachary Amsden wrote:
>
>> Well, I don't think anything is sufficient for a preemptible kernel. I
>> think that's just plain not going to work. You could have a kernel
>> thread that got preempted in a paravirt-op patch point
>>
>
> Patching over the 6 native cases is actually not that bad: they're
> listed below (each one has trailing noops).
>
> cli
> sti
> push %eax; popf
> pushf; pop %eax
> pushf; pop %eax; cli
> iret
> sti; sysexit
>
> If you're at the first insn you don't have to do anything, since you're
> about to replace that code. If you're in the noops, you can just
> advance EIP to the end. You can't be preempted between sti and sysexit,
> since we only use that when interrupts are already disabled. And
> reversing either "push %eax" or "pushf; pop %eax" is fairly easy.
>
> Depending on your hypervisor, you might need to catch those threads who
> are currently doing the paravirt_ops function calls, as well. This
> introduces more (and more complex) cases.
>
Yes, but the problem gets far worse. You don't need to worry about just
those. You need to worry about all that C code that runs in the native
paravirt-ops as well, because you could have preempted it in the middle
of a callout. And the paravirt_ops code isn't isolated in a separate
section (though it well could be).
Zach
next prev parent reply other threads:[~2006-08-23 2:12 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-10 9:35 [PATCH] paravirt.h Rusty Russell
2006-08-10 10:10 ` Rusty Russell
2006-08-10 10:30 ` Andi Kleen
2006-08-10 11:05 ` Rusty Russell
2006-08-10 11:31 ` Andi Kleen
2006-08-10 13:03 ` Zachary Amsden
2006-08-10 15:14 ` Jeremy Fitzhardinge
[not found] ` <44DB54A5.50006@vmware.com>
[not found] ` <44DB6144.2080308@goop.org>
[not found] ` <1155262867.27719.2.camel@localhost.localdomain>
2006-08-11 2:34 ` Jeremy Fitzhardinge
2006-08-10 18:06 ` Jeremy Fitzhardinge
2006-08-19 1:21 ` Adrian Bunk
2006-08-19 2:46 ` Jeremy Fitzhardinge
2006-08-20 8:50 ` Geert Uytterhoeven
2006-08-22 12:56 ` Jeremy Fitzhardinge
2006-08-22 14:08 ` Adrian Bunk
2006-08-22 13:56 ` Alan Cox
2006-08-22 13:44 ` Andi Kleen
2006-08-22 17:16 ` Zachary Amsden
2006-08-22 18:29 ` Arjan van de Ven
2006-08-22 19:30 ` Alan Cox
2006-08-22 19:17 ` Zachary Amsden
2006-08-22 19:26 ` Zachary Amsden
2006-08-22 19:29 ` Arjan van de Ven
2006-08-22 19:43 ` Zachary Amsden
2006-08-22 20:16 ` Andi Kleen
2006-08-22 22:02 ` Zachary Amsden
2006-08-23 1:55 ` Rusty Russell
2006-08-23 2:12 ` Zachary Amsden [this message]
2006-08-23 7:56 ` Arjan van de Ven
2006-08-23 8:44 ` Zachary Amsden
2006-08-23 8:50 ` Andi Kleen
2006-08-23 9:01 ` Zachary Amsden
2006-08-23 9:06 ` Andi Kleen
2006-08-23 9:14 ` Zachary Amsden
2006-08-23 9:20 ` Andi Kleen
2006-08-23 9:36 ` Zachary Amsden
2006-08-23 9:41 ` Andi Kleen
2006-08-23 9:48 ` Zachary Amsden
2006-08-23 9:50 ` Andi Kleen
2006-08-23 10:03 ` Zachary Amsden
2006-08-23 11:24 ` Andi Kleen
2006-08-23 8:56 ` Arjan van de Ven
2006-08-23 8:18 ` Andi Kleen
2006-08-23 8:38 ` Zachary Amsden
2006-08-22 21:36 ` Alan Cox
2006-08-22 13:45 ` Arjan van de Ven
2006-08-22 13:50 ` Andi Kleen
2006-08-22 14:25 ` Adrian Bunk
2006-08-22 14:54 ` Andi Kleen
2006-08-22 17:36 ` Zachary Amsden
2006-08-22 18:35 ` Alan Cox
2006-08-22 14:59 ` Jeremy Fitzhardinge
2006-08-22 15:12 ` Arjan van de Ven
2006-08-22 15:58 ` Alan Cox
2006-08-23 1:35 ` Rusty Russell
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=44EBB97B.9030707@vmware.com \
--to=zach@vmware.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=chrisw@sous-sol.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.osdl.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).