Re: [PATCH] paravirt.h

From: Zachary Amsden
Date: Wed Aug 23 2006 - 04:35:59 EST

Andi Kleen 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, and making all the patch points non-preempt is probably a non-starter (either +12 bytes each or no native inlining).

stop machine deals with preemption. If it didn't it would be unusable
for the purposes the kernel uses it right now (cpu hotplug, module unloading etc.)

Yes, but it can't move pre-empted threads out of a particularly dangerous EIP (like a piece of code we're about to patch over). Or perhaps I am misunderstanding how it deals with preemption, and what it really does is make sure all threads are in userspace or sleep state... which in that case is perfectly fine.

and machine checks. debug traps -- i assume you mean kernel debuggers -- sounds like something that cannot be really controlled though.

How do you control a debugger from the debugee?

I don't think NMI/MCEs are a problem though because NMIs (at least oprofile/nmi watchdog) and MCEs all just have global state that can be changed on a single CPU.

But with paravirt-ops, that global state may include local CPU state, in which paravirt-ops is intimately involved. So they could interrupt in the middle of the patching code, then attempt a paravirt_ops call, which is in an undefined state until the patching is complete. And I would highly expect the debugger to mess with debug registers, which is a paravirt op. NMIs can do plenty of dangerous things to local state as well - reading and writing MSRs or performance counters I would imagine to be quite useful.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at