Thread (53 messages) 53 messages, 9 authors, 2006-08-23

Re: [PATCH] paravirt.h

flat view

From: Rusty Russell <hidden>
Date: 2006-08-23 01:55:34
Also in: lkml

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.

That all said, I've long speculated about a stop_machine which schedules
all the preempted threads, to ensure every thread is in a happy
unpreempt place.  This would involve scheduler hacks, but would allow us
to remove the preempt_disable() calls around try_module_get() and any
other areas which use stop_machine as the write side of locking.

Rusty.
-- 
Help! Save Australia from the worst of the DMCA: http://linux.org.au/law
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help