[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Re: [PATCH] AMD IOMMU: Hanlde sibling deviceassignment correctly



David Edmondson wrote:
> On 7 May 2008, at 2:09pm, Keir Fraser wrote:
>> On 7/5/08 11:17, "Wei Wang2" <wei.wang2@xxxxxxx> wrote:
>> 
>>>> This patch seems to do more than you suggest, for example adding
>>>> an extra iommu hook into setup.c for dom0.
>>> My idea is to let dom0 construct pci device list according to
>>> configuration of pciback.hide=(). If a device is not hidden from
>>> dom0, it might be in use by dom0, then it could be dangerous to
>>> assign any of its siblings to other passthru domain. It is not very
>>> clean to hook into setup.c but I failed to find any better way to
>>> this  :( 
>> 
>> I might be confused about how this works. Are you saying that if a
>> domU gets a device passed-thru that is a sibling of a dom0-driven
>> device, then dom0 will mistakenly have its device's DMAs remapped
>> according to the domU mappings that get set up?
> 
> If a device is behind a PCI-E to PCI bridge there are cases where
> transactions from the device are re-written by the bridge to use the
> requestor id of the bridge. Given that the requestor id is the token
> used by the IOMMU to determine the domain which initiated the IO, this
> effectively means that devices behind a PCI-E to PCI bridge are not
> divisible - they (and the bridge) must all be assigned to the same
> domain.
> 
> At least, that's my understanding :-/
> 

For VT-d, your understanding is correct. Devices behind PCI-E to
PCI/PCI-X bridges can only be collectively assigned to a
single domain. But now it's not implemented yet in Xen.

Randy (Weidong)


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.