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
