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 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().

>>Finally, isn't it inconsistent that only the original device gets its
>>->domain set to the new owner and gets moved to that domain's
>>device list, but neither the upstream bridge nor that bridge's
>><secbus>:00.0 get handled the same way? What if below that
> 
> Per my understanding, the bridge and the <secbus>:00.0 is only for PCI device 
> because all PCI device behind the same pcie2pci bridge should be assigned to 
> the same domain. So if a device is assigned to a domain, the bridge and the 
> <secbus>:00.0 should be the same, so it is not that neccessary to keep that 
> information for the bridge and <secbus>:0.0 .

Hmm, having the hypervisor rely that much on the tools behaving
well doesn't seem too good an idea to me.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel