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

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

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