WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [PATCH 0/2] IOMMU: Handle sibling device assignmentcorre

To: "Wei Wang2" <wei.wang2@xxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 0/2] IOMMU: Handle sibling device assignmentcorrectly (re-send)
From: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxxx>
Date: Wed, 28 May 2008 17:32:57 +0100
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 28 May 2008 09:33:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1211981033.18132.0.camel@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1211981033.18132.0.camel@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcjAxl6lG3EMu86cSQG+YdxaR8urbwAFiDRQ
Thread-topic: [Xen-devel] [PATCH 0/2] IOMMU: Handle sibling device assignmentcorrectly (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

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel