On Mon, Feb 25, 2013 at 03:34:19PM +0200, Gleb Natapov wrote:
> On Mon, Feb 25, 2013 at 11:13:25AM +0000, Zhang, Yang Z wrote:
> > Gleb Natapov wrote on 2013-02-25:
> > > On Mon, Feb 25, 2013 at 11:04:25AM +0000, Zhang, Yang Z wrote:
> > >> Gleb Natapov wrote on 2013-02-25:
> > >>> On Mon, Feb 25, 2013 at 08:42:52AM +0000, Zhang, Yang Z wrote:
> > >>>> Avi Kivity wrote on 2013-02-25:
> > >>>>> I didn't really follow, but is the root cause the need to keep track
> > >>>>> of interrupt coalescing?  If so we can recommend that users use
> > >>>>> KVM_IRQ_LINE when coalescing is unneeded, and move interrupt
> > >>>>> injection with irq coalescing support to vcpu context.
> > >>>> So we can hide the capability KVM_CAP_IRQ_INJECT_STATUS when posted
> > >>> interrupt is enabled to force users doesn't to use
> > >>> KVM_IRQ_LINE_STATUS. Does this acceptable?
> > >>>> 
> > >>>> The only case in KVM that need to know the interrupt injection status 
> > >>>> is
> > > vlapic
> > >>> timer. But since vlapic timer and vcpu are always in same pcpu, so 
> > >>> there is no
> > >>> problem.
> > >>>> 
> > >>> Not really. The primary user of this interface is RTC interrupt
> > >>> re-injection for Windows guests.
> > >> So without KVM_IRQ_LINE_STATUS capability, RTC cannot work well?
> > >> 
> > > Windows guests may experience timedrift under CPU overcommit scenario.
> > Ok, I see. Seems we are stuck. :(
> > Do you have any suggestion to solve or workaround current problem?
> > 
> 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

Can add a capability to QEMU and enable APICv selectively only 
in newer QEMU, which can issue KVM_IRQ_LINE_STATUS on target vcpu
only when necessary (and KVM_IRQ_LINE otherwise).

Even a lock serializing injection is not safe because ON bit is cleared
before XCHG(PIR, 0). Must do something heavier (such as running on
target vcpu context).

> 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.
> 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)

Breaks older userspace?
> 
> Other ideas?

Can HW write a 'finished' bit after 6 in the reserved area? Suppose its
not a KVM-specific problem?

--
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

Reply via email to