Messages in this thread |  | | | Date | Wed, 23 Aug 2006 01:38:38 -0700 | | From | Zachary Amsden <> | | Subject | Re: [PATCH] paravirt.h |
| |
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.
Zach - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |