Am 14.12.2010 um 09:42 schrieb Avi Kivity <a...@redhat.com>: > On 12/14/2010 02:24 AM, Alexander Graf wrote: >> On 14.12.2010, at 01:18, Scott Wood wrote: >> >> > On Tue, 14 Dec 2010 00:54:38 +0100 >> > Alexander Graf<a...@csgraf.de> 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. >> >> Hrm, is that window really that important? There's usually plenty of >> interrupts and mmios coming through to always have some check going on. > > What about when "usually" doesn't happen? Tickless kernel, everything's > asleep, interrupt missed, system is dead.
Even tickless guest kernels will get out of guest context from time to time, simply because if there are no interrupts on the host, the host is useless - it would only have a single, isolated task running that wouldn't even be able to use the network. But yes, if we can go without black spots, we should :) Alex > -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
