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