Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

["Goel, Sameer" <sgoel@xxxxxxxxxxxxxx>]

On 12/29/2016 7:04 AM, Julien Grall wrote:

> 
> ### Finding the StreamID and DeviceID
> 
> The static table IORT (see [5]) will provide information that will help to
> deduce the StreamID and DeviceID from a given RID.
>

IORT table will also need some information on PCI seg to parse through the table
and find the required SMMU. Should, we consider the API to be similar to Linux.
This will mandate pulling in parts of fw_spec which will make the bookkeeping 
for 
SMMUs easier. 

Also, for arm64 will be be reusing the current definition of struct pci_device? 
(SBDF specifically)

- Sameer 
 
> ## Device Tree
> 
> ### Host bridges
> 
> Each Device Tree node associated to a host bridge will have at least the
> following properties (see bindings in [8]):
>     - device_type: will always be "pci".
>     - compatible: a string indicating which driver to instantiate
> 
> The node may also contain optional properties such as:
>     - linux,pci-domain: assign a fix segment number
>     - bus-range: indicate the range of bus numbers supported
> 
> When the property linux,pci-domain is not present, the operating system would
> have to allocate the segment number for each host bridges. Because the
> algorithm to allocate the segment is not specified, it is necessary for
> DOM0 and Xen to agree on the number before any PCI is been added.
> 
> ### Finding the StreamID and DeviceID
> 
> ### StreamID
> 
> The first binding existing (see [9]) for SMMU didn't have a way to describe 
> the
> relationship between RID and StreamID, it was assumed that StreamID == 
> RequesterID.
> This bindins has now been deprecated in favor of a generic binding (see [10])
> which will use the property "iommu-map" to describe the relationship between
> an RID, the associated IOMMU and the StreamID.
> 
> ### DeviceID
> 
> The relationship between the RID and the DeviceID can be found using the
> property "msi-map" (see [11]).
> 
> # Discovering PCI devices
> 
> Whilst PCI devices are currently available in DOM0, the hypervisor does not
> have any knowledge of them. The first step of supporting PCI passthrough is
> to make Xen aware of the PCI devices.
> 
> Xen will require access to the PCI configuration space to retrieve information
> for the PCI devices or access it on behalf of the guest via the emulated
> host bridge.
> 
> ## Discovering and register hostbridge
> 
> Both ACPI and Device Tree do not provide enough information to fully
> instantiate an host bridge driver. In the case of ACPI, some data may come
> from ASL, whilst for Device Tree the segment number is not available.
> 
> So Xen needs to rely on DOM0 to discover the host bridges and notify Xen
> with all the relevant informations. This will be done via a new hypercall
> PHYSDEVOP_pci_host_bridge_add. The layout of the structure will be:
> 
> struct physdev_pci_host_bridge_add
> {
>     /* IN */
>     uint16_t seg;
>     /* Range of bus supported by the host bridge */
>     uint8_t  bus_start;
>     uint8_t  bus_nr;
>     uint32_t res0;  /* Padding */
>     /* Information about the configuration space region */
>     uint64_t cfg_base;
>     uint64_t cfg_size;
> }
> 
> DOM0 will issue the hypercall PHYSDEVOP_pci_host_bridge_add for each host
> bridge available on the platform. When Xen is receiving the hypercall, the
> the driver associated to the host bridge will be instantiated.
> 
> XXX: Shall we limit DOM0 the access to the configuration space from that
> moment?
> 
> ## Discovering and register PCI
> 
> Similarly to x86, PCI devices will be discovered by DOM0 and register
> using the hypercalls PHYSDEVOP_pci_add_device or PHYSDEVOP_manage_pci_add_ext.
> 
> By default all the PCI devices will be assigned to DOM0. So Xen would have
> to configure the SMMU and Interrupt Controller to allow DOM0 to use the PCI
> devices. As mentioned earlier, those subsystems will require the StreamID
> and DeviceID. Both can be deduced from the RID.
> 
> XXX: How to hide PCI devices from DOM0?
> 
> # Glossary
> 
> ECAM: Enhanced Configuration Mechanism
> SBDF: Segment Bus Device Function. The segment is a software concept.
> MSI: Message Signaled Interrupt
> SPI: Shared Peripheral Interrupt
> LPI: Locality-specific Peripheral Interrupt
> ITS: Interrupt Translation Service
> 
> # Bibliography
> 
> [1] PCI firmware specification, rev 3.2
> [2] https://www.spinics.net/lists/linux-pci/msg56715.html
> [3] https://www.spinics.net/lists/linux-pci/msg56723.html
> [4] https://www.spinics.net/lists/linux-pci/msg56728.html
> [5] 
> http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf
> [6] https://www.spinics.net/lists/kvm/msg140116.html
> [7] http://www.firmware.org/1275/bindings/pci/pci2_1.pdf
> [8] Documents/devicetree/bindings/pci
> [9] Documents/devicetree/bindings/iommu/arm,smmu.txt
> [10] Document/devicetree/bindings/pci/pci-iommu.txt
> [11] Documents/devicetree/bindings/pci/pci-msi.txt
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> https://lists.xen.org/xen-devel
> 

-- 
 Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, 
Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel