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/
Home Products Support Community News


[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 16:10:31 +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 01:12:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <49D1E917.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> <EADF0A36011179459010BDF5142A457511A788E9@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <49D1E917.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acmx1jsD0qvyawRKQLqGdahVpjCKsAAAF3aw
Thread-topic: co-assignment needs for PCI devices
Jan Beulich wrote:
>>>> "Cui, Dexuan" <dexuan.cui@xxxxxxxxx> 31.03.09 09:48 >>>
>> Jan Beulich wrote:
>>> 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...    
> But - for the sake of my education, if you forgive - you didn't
> answer whether there is a one-device-per-secondary-bus restriction on
> PCIe...  

My knowledge to the question is yes, and the "one-device" can be a 
single-function device or a multi-function device.

-- Dexuan

Xen-devel mailing list