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