[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.