WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] RE: VT-d device assignment may fail (regression from Xen c/s

>>> 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