[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] RE: VT-d device assignment may fail (regression from Xen c/s 19805:2f1fa2215e60)
>>> On 25.10.10 at 17:52, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote: > >>-----Original Message----- >>From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx] >>Sent: Monday, October 25, 2010 4:59 PM >>To: Han, Weidong; Jiang, Yunhong >>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx >>Subject: RE: VT-d device assignment may fail (regression from Xen c/s >>19805:2f1fa2215e60) >> >>>>> On 25.10.10 at 09:05, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote: >>>>From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx] >>> What's the removed bus/devfn check you mean? I didn't catch it in the patch. >> >>There used to be >> >> if ( (secbus != bus) && (secdevfn != 0) ) >> >>guarding the second call to domain_context_mapping_one(). > > I didn't understand quite clearly of the oriignal check (the secbus!= bus && > secdevfn != 0). But seems the new code should be ok, we only need setup the > devfn=0 for the pcie2pci bridge, at least according to the vt-d spec. It obviously isn't okay in the case where the original device is the one at <secbus>:00.0 (and avoiding the attempt to map the device a second time was - afaict - the intention of that check). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |