> -----Original Message----- > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Monday, October 12, 2015 6:42 PM > To: Wu, Feng; xen-devel@lists.xen.org > Cc: Tian, Kevin; Zhang, Yang Z; Jan Beulich; Keir Fraser; George Dunlap > Subject: Re: [PATCH v8 01/17] VT-d Posted-intterrupt (PI) design > > On 12/10/15 09:54, Feng Wu wrote: > > Add the design doc for VT-d PI. > > > > CC: Kevin Tian <kevin.t...@intel.com> > > CC: Yang Zhang <yang.z.zh...@intel.com> > > CC: Jan Beulich <jbeul...@suse.com> > > CC: Keir Fraser <k...@xen.org> > > CC: Andrew Cooper <andrew.coop...@citrix.com> > > CC: George Dunlap <george.dun...@eu.citrix.com> > > Signed-off-by: Feng Wu <feng...@intel.com> > > Reviewed-by: Kevin Tian <kevin.t...@intel.com> > > Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> > > --- > > docs/misc/vtd-pi.txt | 332 > +++++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 332 insertions(+) > > create mode 100644 docs/misc/vtd-pi.txt > > > There appears to be a race condition here. Consider the following setup. > > VCPU A with PID A > VCPU B with PID B > > Both VCPUs have Posted Interrupts set up and devices assigned. > > VCPU A is running in non-root mode on CPU X, and VCPU B is on the > blocked list for CPU X. i.e. Both PID A and B have the same ndst and nv.
vCPUA is running in non-root mode, so its nv is 'posted_intr_vector', and vCPUS is blocked, so its nv is 'pi_wakeup_vector', the NV is different, so the situation you describe cannot happen. Thanks, Feng > > An interrupt arrives to PID B, setting B.ON and sending a notification > vector for CPU X. > > At this point, according to the spec, CPU X will collect interrupt > information from PID A and inject any vectors locally. > > This this accurate? If so, what causes a #VMEXIT to occur and for Xen > to service the blocked list on CPU X? > > ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
