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

[Yang Zhang <yang.zhang.wz@xxxxxxxxx>]

On 2016/8/22 22:57, Jan Beulich wrote:
> > > > On 22.08.16 at 15:09, <yang.zhang.wz@xxxxxxxxx> wrote:
> > On 2016/8/22 20:04, Jan Beulich wrote:
> > > > > > On 22.08.16 at 13:41, <xuquan8@xxxxxxxxxx> wrote:
> > > > On August 22, 2016 6:36 PM, <JBeulich@xxxxxxxx> wrote:
> > > > > > > > On 19.08.16 at 14:58, <xuquan8@xxxxxxxxxx> wrote:
> > > > > > From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
> > > > > > From: Quan Xu <xuquan8@xxxxxxxxxx>
> > > > > > Date: Fri, 19 Aug 2016 20:40:31 +0800
> > > > > > Subject: [RFC PATCH] 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. The guest receives
> > > > > > more
> > > > > > periodic timer interrupt.
> > > > > >
> > > > > > If the periodic timer interrut is delivered and not the highest priority,
> > make
> > > > > > Xen be aware of this case to decrease the count of pending periodic timer
> > > > > > interrupt.
> > > > > I can see the issue you're trying to address, but for one - doesn't
> > > > > this lead to other double accounting, namely once the pt irq becomes
> > > > > the highest priority one?
> > > > It is does NOT lead to other double accounting..
> > > > As if the pt irq becomes the highest priority one, the intack is pt one..
> > > > Then:
> > > >
> > > >  +        else
> > > >  +            pt_intr_post(v, intack);
> > > As just said in reply to Yang: If this is still the same interrupt instance
> > > as in a prior run through here which took the if() branch, this change
> > > looks like having the potential of double accounting.
> > This cannot happen: if pt intr is the second priority one, then
> > corresponding vIRR bit will be cleared by hardware while the highest
> > priority intr is delivered to guest. And the next vmx_intr_assit cannot
> > aware of it since the vIRR bit is zero.
> In addition to what Quan said in response - aren't you mixing up
> vISR and vIRR here? I can see vISR being clear when a higher prio
Right. It should be ISR not IRR.

> interrupt gets delivered (unless that happened to interrupt the pt
> interrupt handler), but I would hope that virtualized behavior
> matches non-virtualized one in that vIRR accumulates requests.
--
Yang
Alibaba Cloud Computing

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