[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3] x86/apicv: fix RTC periodic timer and apicv issue
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |