Re: [Xen-devel] [PATCH v3] x86/apicv: fix RTC periodic timer and apicv issue

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.12.16 at 06:54, <xuquan8@xxxxxxxxxx> wrote:
> On December 20, 2016 1:37 PM, Tian, Kevin wrote:
>>> From: Xuquan (Quan Xu) [mailto:xuquan8@xxxxxxxxxx]
>>> Sent: Friday, December 16, 2016 5:40 PM
>>>
>>> From 89fffdd6b563b2723e24d17231715bb8c9f24f90 Mon Sep 17 00:00:00
>>2001
>>> From: Quan Xu <xuquan8@xxxxxxxxxx>
>>> Date: Fri, 16 Dec 2016 17:24:01 +0800
>>> Subject: [PATCH v3] x86/apicv: fix RTC periodic timer and apicv issue
>>>
>>> When Xen apicv is enabled, wall clock time is faster on Windows7-32
>>> guest with high payload (with 2vCPU, captured from xentrace, in high
>>> payload, the count of IPI interrupt increases rapidly between these
>>> vCPUs).
>>>
>>> If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector
>>> 0xd1) are both pending (index of bit set in vIRR), unfortunately, the
>>> IPI intrrupt is high priority than periodic timer interrupt. Xen
>>> updates IPI interrupt bit set in vIRR to guest interrupt status (RVI)
>>> as a high priority and apicv (Virtual-Interrupt Delivery) delivers IPI
>>> interrupt within VMX non-root operation without a VM-Exit. Within VMX
>>> non-root operation, if periodic timer interrupt index of bit is set in
>>> vIRR and highest, the apicv delivers periodic timer interrupt within
>>> VMX non-root operation as well.
>>>
>>> But in current code, if Xen doesn't update periodic timer interrupt
>>> bit set in vIRR to guest interrupt status (RVI) directly, Xen is not
>>> aware of this case to decrease the count (pending_intr_nr) of pending
>>> periodic timer interrupt, then Xen will deliver a periodic timer interrupt
>>again.
>>>
>>> And that we update periodic timer interrupt in every VM-entry, there
>>> is a chance that already-injected instance (before EOI-induced exit
>>> happens) will incur another pending IRR setting if there is a VM-exit
>>> happens between virtual interrupt injection (vIRR->0, vISR->1) and
>>> EOI-induced exit (vISR->0), since pt_intr_post hasn't been invoked
>>> yet, then the guest receives more periodic timer interrupt.
>>>
>>> So we set eoi_exit_bitmap for intack.vector when it's higher than
>>> pending periodic time interrupts. This way we can guarantee there's
>>> always a chance to post periodic time interrupts when periodic time
>>> interrupts becomes the highest one.
>>>
>>> Signed-off-by: Quan Xu <xuquan8@xxxxxxxxxx>
>>
>>I suppose you've verified this new version, but still would like get your
>>explicit confirmation - did you still see time accuracy issue in your side?
>>Have you tried other guest OS types other than Win7-32?
>>
> 
> I only verified it on win7-32 guest..
> I will continue to verify it on other windows guest (I think windows is 
> enough, right?)

No, I don't think Windows alone is sufficient for verification. People
run all kinds of OSes as HVM guests, and your change should not
negatively impact them. At the very least you want to also try Linux.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel