> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
> Sent: Friday, December 16, 2016 5:40 PM
>
> From 89fffdd6b563b2723e24d17231715bb8c9f24f90 Mon Sep 17 00:00:00 2001
> From: Quan Xu <xuqu...@huawei.com>
> 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 <xuqu...@huawei.com>
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?
> ---
> 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);
>
> /* we need update the RVI field */
> __vmread(GUEST_INTR_STATUS, &status);
> @@ -334,7 +342,8 @@ void vmx_intr_assist(void)
> __vmwrite(EOI_EXIT_BITMAP(i),
> v->arch.hvm_vmx.eoi_exit_bitmap[i]);
> }
>
> - pt_intr_post(v, intack);
> + if ( intack.vector == pt_vector )
> + pt_intr_post(v, intack);
> }
> else
> {
> --
> 1.7.12.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
