[PATCH 0/2] IOMMU: Handle sibling device assignment correctly (re-send)

[PATCH 0/2] IOMMU: Handle sibling device assignment correctly (re-send)

[Wei Wang2]

This patch set is revised according to comments from community. Domctl
interface is extended to allow libxc retrieve device group information
from hypervisor. Vendor-specific iommu_ops is also extended by adding a
new operation "get_device_group_id()", which is currently a null pointer
but could be implemented later for vt-d. 

Error will be raised from tools side when user trying to assign PCI
device with a sibling device being driven by dom0. User will keep being
prompted until he has hidden the entire device group (at least, the
sibling devices driven by dom0) in dom0 kernel parameter. Hopefully this
framework could be flexible enough to support both amd iommu and vt-d. 

The following 2 cases are not covered by this patch, but should be easy
to handle.
* Checking for hot-plug devices (maybe we can delay calling
ImageHandler.signalDeviceModel() until all checks are done?)
* Checking for splitted device group between different passthru domains

Looking forward to your comments, thanks!

Wei

Signed-off-by: Wei Wang <wei.wang2@amd.com>
-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy

RE: [PATCH 0/2] IOMMU: Handle sibling device assignmentcorrectly (re-send)

[Ian Pratt]

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

> This patch set is revised according to comments from community. Domctl
> interface is extended to allow libxc retrieve device group information
> from hypervisor. Vendor-specific iommu_ops is also extended by adding a
> new operation "get_device_group_id()", which is currently a null
> pointer
> but could be implemented later for vt-d.
> 
> Error will be raised from tools side when user trying to assign PCI
> device with a sibling device being driven by dom0. User will keep being
> prompted until he has hidden the entire device group (at least, the
> sibling devices driven by dom0) in dom0 kernel parameter. Hopefully
> this
> framework could be flexible enough to support both amd iommu and vt-d.
> 
> The following 2 cases are not covered by this patch, but should be easy
> to handle.
> * Checking for hot-plug devices (maybe we can delay calling
> ImageHandler.signalDeviceModel() until all checks are done?)
> * Checking for splitted device group between different passthru domains

With this patch, what happens if you assign a device that is behind a bridge. Does the guest get all the devices behind the bridge?

This would be reasonable behaviour, particularly if we prevent other VMs from claiming the sibling devices.

Ian


[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

RE: [PATCH 0/2] IOMMU: Handle sibling device assignmentcorrectly (re-send)

[Wei Wang2]

On Wed, 2008-05-28 at 17:32 +0100, Ian Pratt wrote:
> > This patch set is revised according to comments from community. Domctl
> > interface is extended to allow libxc retrieve device group information
> > from hypervisor. Vendor-specific iommu_ops is also extended by adding a
> > new operation "get_device_group_id()", which is currently a null
> > pointer
> > but could be implemented later for vt-d.
> > 
> > Error will be raised from tools side when user trying to assign PCI
> > device with a sibling device being driven by dom0. User will keep being
> > prompted until he has hidden the entire device group (at least, the
> > sibling devices driven by dom0) in dom0 kernel parameter. Hopefully
> > this
> > framework could be flexible enough to support both amd iommu and vt-d.
> > 
> > The following 2 cases are not covered by this patch, but should be easy
> > to handle.
> > * Checking for hot-plug devices (maybe we can delay calling
> > ImageHandler.signalDeviceModel() until all checks are done?)
> > * Checking for splitted device group between different passthru domains
> 
> With this patch, what happens if you assign a device that is behind a bridge. Does the guest get all the devices behind the bridge?
> 
> This would be reasonable behaviour, particularly if we prevent other VMs from claiming the sibling devices.
> 
> Ian
This patch aims to prevent a single device group from being splitted
between dom0 and passthru domain if some of sibling devices in this
group are driven by dom0.  A successful device assignment can only
happen if all the sibling devices are hidden from dom0 or non of them
are used by dom0. However, this patch does not extend the default
behavior of device assignment, only the single device is assigned event
it is behind  a bridge. 

IMO, it is more reasonable to just a assigned a single device behind a
bridge than to give target guest the whole group? Other sibling devices
in this group still get chance to be assigned to the same target domain
dynamically. If the target domain is not the same, assignment will be
rejected. To do this , we might have a global structure to indicate the
owner of each device group. 

-Wei







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

RE: [PATCH 0/2] IOMMU: Handle sibling deviceassignmentcorrectly (re-send)

[Ian Pratt]

> IMO, it is more reasonable to just a assigned a single device behind a
> bridge than to give target guest the whole group? Other sibling
devices
> in this group still get chance to be assigned to the same target
domain
> dynamically. If the target domain is not the same, assignment will be
> rejected. To do this , we might have a global structure to indicate
the
> owner of each device group.

Yes, that's the best behaviour.

Thanks,
Ian