IOMMU: Handle sibling device assignment correctly (re-send)
cover IOMMU: Handle sibling device assignment correctly (re-send)
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
Signature · 12 lines
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)
Quoted 14 lines
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_opsis 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.
Quoted 5 lines
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 callingImageHandler.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
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
RE: [PATCH 0/2] IOMMU: Handle sibling device assignmentcorrectly (re-send)
Quoted 20 lines · Ian Pratt
Quoted 14 lines
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_opsis 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.Quoted 5 lines
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 callingImageHandler.signalDeviceModel()until all checks are done?)
* Checking for splitted device group between different passthru domains
Quoted 5 lines
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
Quoted 4 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
RE: [PATCH 0/2] IOMMU: Handle sibling deviceassignmentcorrectly (re-send)
Quoted 2 lines
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
Quoted 1 line
in this group still get chance to be assigned to the same target
domain
Quoted 2 lines
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
Quoted 1 line
owner of each device group.
Yes, that's the best behaviour.
Thanks,
Ian