From: Zachary Amsden <zach@vmware.com>
To: Andi Kleen <ak@suse.de>
Cc: Arjan van de Ven <arjan@infradead.org>,
virtualization@lists.osdl.org,
Jeremy Fitzhardinge <jeremy@goop.org>,
Andrew Morton <akpm@osdl.org>, Chris Wright <chrisw@sous-sol.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] paravirt.h
Date: Tue, 22 Aug 2006 15:02:52 -0700 [thread overview]
Message-ID: <44EB7F0C.60402@vmware.com> (raw)
In-Reply-To: <p73y7tg7cg7.fsf@verdi.suse.de>
Andi Kleen wrote:
> Zachary Amsden <zach@vmware.com> writes:
>
>> That is a really nasty problem. You need a synchronization primitive
>> which guarantees a flat stack, so you can't do it in the interrupt
>> handler as I have tried to do. I'll bang my head on it awhile. In
>> the meantime, were there ever any solutions to the syscall patching
>> problem that might lend me a clue as to what to do (or not to do, or
>> impossible?).
>>
>
> stop_machine_run() solves the problem I think. It is currently not
> exported though. I don't think there's anything in there that couldn't
> be reimplemented in a module, but then we could also just export it
> if there's a useful user.
>
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, and making all
the patch points non-preempt is probably a non-starter (either +12 bytes
each or no native inlining). Finding out after the fact that you have a
kernel thread that was preempted in a patch point is very hard work, but
it is possible. The fixing it up is where you need to take liberties
with reality.
stop_machine_run() is almost what I want, but even that is not
sufficient. You also need to disable NMIs and debug traps, which is
pretty hairy, but doable. The problem with stop_machine_run() is that I
don't just want the kernel to halt running on remote CPUs, I want the
kernel on all CPUs to actually do something simultaneously - the entry
into paravirt mode requires a hypervisor call on each CPU, and
stop_machine() doesn't provide a facility to fire a callback on each CPU
from the stopmachine state.
Since this code is so rather, um, custom, I was going to reimplement
stop_machine in the module.
Zach
next prev parent reply other threads:[~2006-08-22 22:02 UTC|newest]
Thread overview: 66+ 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 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-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 14:08 ` Adrian Bunk
2006-08-22 13:56 ` Alan Cox
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 19:43 ` Zachary Amsden
2006-08-22 20:16 ` Andi Kleen
2006-08-22 22:02 ` Zachary Amsden [this message]
2006-08-23 1:55 ` Rusty Russell
2006-08-23 1:55 ` Rusty Russell
2006-08-23 2:12 ` Zachary Amsden
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 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: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: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 18:35 ` Alan Cox
2006-08-22 14:59 ` Jeremy Fitzhardinge
2006-08-22 15:12 ` Arjan van de Ven
2006-08-22 15:12 ` Arjan van de Ven
2006-08-22 15:58 ` Alan Cox
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=44EB7F0C.60402@vmware.com \
--to=zach@vmware.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=chrisw@sous-sol.org \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--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 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.