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: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 0/2] IOMMU: Handle sibling device assignmentcorrectly (re-send)
From: Wei Wang2 <wei.wang2@xxxxxxx>
Date: Thu, 29 May 2008 11:12:47 +0200
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Thu, 29 May 2008 02:13:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <DD74FBB8EE28D441903D56487861CD9D2F46CFB4@xxxxxxxxxxxxxxxxxxxxxx>
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> <DD74FBB8EE28D441903D56487861CD9D2F46CFB4@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



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