Marcelo Tosatti wrote on 2013-02-25: > 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? > > Depend on knowledge about atomicity (item 5 IIRC) of the sequence > in the manual. I am sure it is not atomic: tmp_pir=xhcg(pir, 0) irr |= tmp_pir Best regards, Yang -- 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
