> -----Original Message----- > From: George Dunlap [mailto:george.dun...@citrix.com] > Sent: Tuesday, September 22, 2015 10:28 PM > To: Wu, Feng; Dario Faggioli > Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew > Cooper; Jan Beulich > Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core > logic > handling > > On 09/22/2015 02:25 PM, Wu, Feng wrote: > >>> But if we want to avoid spurious PI interrupts when running idle, then > >>> yes, we need *some* kind of a hook on the lazy context switch path. > >>> > >>> /me does some more thinking... > >> > >> To be honest, since we'll be get spurious PI interrupts in the > >> hypervisor all the time anyway, I'm inclined at the moment not to worry > >> to much about this case. > > > > Why do you say "we'll be get spurious PI interrupts in the hypervisor all > > the > time"? > > > > And could you please share what is your concern to handle this case to avoid > > such spurious PI interrupts? Thanks! > > So please correct me if I'm wrong in my understanding: > > * When a vcpu is in runstate "running", with PI enabled, you have the PI > vector set to "posted_interrupt_vector", SN=0. > > * When in this state in non-root mode, PI interrupts result in an > interrupt being delivered directly to the guest. > > * When in this state in root mode, PI interrupts result in a > posted_interrupt_vector interrupt being delivered to Xen. > > Is that the case?
Exactly, it is how PI works today. Thanks, Feng > > So basically, if the PI happens to come in when the guest is making a > hypercall, or the guest is doing any other number of things that involve > the hypervisor, then Xen will get a "spurious" PI interrupt -- spurious > because there's nothing Xen actually needs to do about it; the guest > interrupt will be delivered the next time we do a VMENTER. > > So spurious PI interrupts are already going to happen from time to time > -- they're not really that big of a deal. Having them happen when a VM > is running a tasklet or idle waiting for qemu isn't such a big deal either. > > -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
