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

[Ross Philipson <Ross.Philipson@xxxxxxxxxx>]

Thanks for the questions and answers regarding the below topics :) I was just 
working on related functionality and was arriving at some of the same questions 
(specifically the last one regarding PCIe one-device-per-secondary-bus).

I had another question/comment related to this topic and the xend code that is 
locating co-assigned PCI devices. It seems the routine 
find_the_uppermost_pci_bridge() is meant to find the uppermost bridge device 
that bridges *TO* a PCI/PCI-X bus. Per the logic this makes sense that it would 
be any non-PCIe bridge but also a PCIe-to-PCI/PCI-X bridge which is tested for 
earlier when the device type is determined. So far this all seems to make 
sense. But in the routine above, the logic seems like it would actually go past 
what I would think of as the topmost PCI/PCI-X bridge and find the next parent 
(note that if dev_type == DEV_TYPE_PCIe_BRIDGE, the loop ends but that device 
is taken to be the target bridge). Is this correct or is there an issue in this 
logic?

Thanks
Ross

-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Cui, Dexuan
Sent: Tuesday, March 31, 2009 4:11 AM
To: Jan Beulich
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] RE: 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.

Thanks,
-- Dexuan


_______________________________________________
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