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

[Xen-devel] RE: co-assignment needs for PCI devices

To: Jan Beulich <jbeulich@xxxxxxxxxx>
Subject: [Xen-devel] RE: co-assignment needs for PCI devices
From: "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>
Date: Tue, 31 Mar 2009 15:48:51 +0800
Accept-language: zh-CN, en-US
Acceptlanguage: zh-CN, en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 31 Mar 2009 00:50:45 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <49D1DDEF.76E4.0078.0@xxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <49D1DDEF.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acmxz5dMdD6QhSOrQju87dbN2HGThwAAncUg
Thread-topic: co-assignment needs for PCI devices
Jan Beulich wrote:
> c/s 18046 adds the requirement to co-assign PCI devices behind
> bridges/ PCIe functions on the same device when the (perhaps
> individual) device/ function intended to be assigned doesn't support
> FLR and doesn't sit on bus 0. For non-IOMMU environments (which are
> insecure anyway) this 
> could be considered a regression, since passing through individual
> devices/ functions didn't know such a restriction earlier.
Yes, this may not proper for the non-IOMMU case. I planned to fix it, but 
haven't done that yet... I'd appreciate anybody who can help to do that. :-)
We need to consider IOMMU case, non-IOMMU case and 'hybrid case'(namely, the 
xen parameter iommu=on,no-pv).

> Also, being not really knowledgeable about all the differences between
> PCIe and PCI, I'd appreciate some clarification on why on PCIe it is
> possible and correct to do a secondary bus reset when targeting just
> the (PCIe) functions of a single device - to me this seems to imply
> that there's a one-device-per-non-root-bus restriction there.
According to VT-d spec (section 3.6.1: Identifying Origination of DMA 
Requests), PCI devices behind the same uppermost PCI/PCI-X bridge must be 
co-assigned to the same guest. PCIe devices have not such a constraint.

FLR (Functional Level Reset) is used to quiesce an assigned device when we 
destroy a guest or we detach the device from the guest. If a PCIe device has no 
standard FLR capability, we'll try to use SecondaryBusReset as a way to do FLR. 
Unluckily,  SecondaryBusReset resets all the devices behind the bridge, so for 
a multi-function PCIe device without FLR capability, we require they have to be 
co-assigned to the same guest --  certainly this is only for iommu case and for 
non-iommu case this requirement may be not proper and we shoud fix it...

Thanks,
-- Dexuan


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