On Tue, 14 Dec 2010 00:54:38 +0100 Alexander Graf <alex@xxxxxxxxx> wrote: > On 13.12.2010, at 20:03, Scott Wood wrote: > > [1] Speaking of which, what happens when an interrupt is raised in the > > middle of a paravirt critical section? KVM will hold off the > > interrupt delivery if it sees the critical flag set, but when will it > > deliver the postponed interrupt? Seems like it will wait until the next > > time an exit happens for some other reason. > > mtmsr with IF=1 checks for pending interrupts and enables them with a real mtmsr then which again checks interrupts in vm entry, so it immediately gets injected :). Right, but I'm not talking about an interrupt that happens when the virtual EE bit is zero. I'm talking about an interrupt that happens right in the middle of the paravirt sequence -- after reading int_pending, but before setting critical to r2. It seems like the race window is just narrowed, not eliminated. One option would be for KVM to single-step the guest until critical != r1. It should only be a few instructions, and it shouldn't happen very often. This is probably the better option. Another option would be to dispense with the critical section altogether, by having the guest assume that these instructions clobber certain registers -- though that would not be pleasant to maintain, as you'd have to verify every place the instruction is used, now or in the future. A variant of this would be to use an out-of-section annotation (similar to get_user et al) so that each instance of the instruction has to explicitly opt-in. The rewritten code would be faster this way, though it may not make any practical difference. -Scott -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
