> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com] > Sent: Tuesday, December 20, 2016 5:39 PM > > On December 20, 2016 4:32 PM, Jan Beulich wrote: > >>>> On 20.12.16 at 06:54, <xuqu...@huawei.com> wrote: > >> On December 20, 2016 1:37 PM, Tian, Kevin wrote: > >>>> 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? > >>> > >> > >> 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... > >
Using 'date' is OK. The key is that you need find a workload which can impose enough IPIs as you observed in Windows guest side. Anyway, think about the situation you described in the patch msg and then generate a test environment accordingly. :-) Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
