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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.12.16 at 10:38, <xuquan8@xxxxxxxxxx> wrote:
> On December 20, 2016 4:32 PM, Jan Beulich wrote:
>>>>> 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.
> 
> Cloud I use 'date' command to test it? As I only have server version of 
> LINUX, no desktop version...

Well - I'm really not sure how to best test this.

Jan


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