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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
