[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 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |