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

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

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.
--
Yang
Alibaba Cloud Computing

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