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

["Xuquan (Quan Xu)" <xuquan8@xxxxxxxxxx>]

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?)


>> ---
>>  xen/arch/x86/hvm/vmx/intr.c | 15 ++++++++++++---
>>  1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
>> index 639a705..d7a5716 100644
>> --- a/xen/arch/x86/hvm/vmx/intr.c
>> +++ b/xen/arch/x86/hvm/vmx/intr.c
>> @@ -315,9 +315,17 @@ void vmx_intr_assist(void)
>>          * Set eoi_exit_bitmap for periodic timer interrup to cause
>EOI-induced VM
>>          * exit, then pending periodic time interrups have the chance
>to be injected
>>          * for compensation
>> +        * 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
>>          */
>> -        if (pt_vector != -1)
>> -            vmx_set_eoi_exit_bitmap(v, pt_vector);
>> +        if ( pt_vector != -1 ) {
>> +            if ( intack.vector > pt_vector )
>> +                vmx_set_eoi_exit_bitmap(v, intack.vector);
>> +            else
>> +                vmx_set_eoi_exit_bitmap(v, pt_vector);
>> +        }
>
>Above can be simplified as one line change:
>       if ( pt_vector != -1 )
>               vmx_set_eoi_exit_bitmap(v, intack.vector);
>

Agreed.. I found this change doesn't look good, but I had no idea to improve 
it.. thanks.
Also sorry for the late v3.

Quan



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