[Xen-devel] Re: [PATCH] AMD IOMMU: Hanlde sibling device assignment correctly

[Wei Wang2 <wei.wang2@xxxxxxx>]

On Wed, 2008-05-07 at 14:09 +0100, 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?

I have encountered a problem on my testing machine. When I assign a usb
controller ,which shares the same device ID of a sata controller belong
to dom0, dom0 hangs immediately.  The current solution is that when
hiding a pci device from dom0, its sibling device must also be hidden.
Therefore, I need to parse pciback.hide from Xen side..

> Is it possible to do this more dynamically from the tools? I.e, working out
> sibling groups at the time we build a pass-thru domain, and at that point
> fail the pass-thru if dom0 or any other domU is driving any device in the
> group? Seems a nicer level to do the checks and raise errors. You might want
> to some conflict checking in Xen, of course, just to sanity-check that noone
> tries to set up two different mappings on the same HT or PCIe identifier.
Yes, that is my first thought. The question is only dom0 knows about
pciback.hide information. Current iommu code construct device list  no
matter whether devices are actually hidden from dom0. Is it better to
just allow hidden devices to be added into the device list?

> Basically I think this patch is ugly. :-)
Yes, I admit that.  the purpose of this patch is maybe just raise a problem for 
further discussion. ;)

Wei

>  -- Keir
> 
> 
> 



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