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

Reply via email to