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

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

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