[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)
CC Allen for more input. Thanks --jyh >-----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(). > >>>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 |