On Mon, Feb 25, 2013 at 06:50:40PM +0200, Avi Kivity wrote: > >> > > I see a couple of possible solutions: > > 1. Do what Avi said. Make KVM_IRQ_LINE_STATUS be synchronous. Cons: > > current QEMU uses KVM_IRQ_LINE_STATUS always and it means that it > > will be slow on newer kernels > > You could backport the qemu change, verify that it builds, and push it > to stable branches. It's hardly ideal but if nothing else comes up > then it's a solution. > > > > 2. Make KVM_IRQ_LINE_STATUS report coalescing only when vcpu is not > > running during injection. This assumes that if vcpu is running and does > > not process interrupt it is guest fault and the same can happen on real > > HW too. Coalescing when vcpu is not running though is the result of CPU > > overcommit and should be reported. Cons interface definition is kind of > > murky. > > You still have a window where the vcpu is scheduled out with guest > interrupts disabled, then scheduled back in and before it manages to > handle the interrupt, the second one hits. > Yes, definitely not ideal solution. > It's worth testing though. > Yes again. Windows almost never disables interrupts and RTC interrupt is of highest priority. > > 3. Do not report KVM_IRQ_LINE_STATUS capability and move RTC to use EOI > > notifiers for interrupt reinjection. This requires us to add interface > > for reporting EOI to userspace. This is not in the scope of this > > patchset. Cons: need to introduce new interface (and the one that will > > not work on AMD BTW) > > > > Other ideas? > > 1. inject RTC interrupt > 2. not see EOI > 3. inject RTC interrupt > 4. due to 2, report coalesced > That's the 3 in my list, no? > AMD can still use IRR test-and-set. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
