Re: [Xen-devel] [RFC] [Draft Design v2] ACPI/IORT Support in Xen.

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi Manish,

On 08/11/17 14:38, Manish Jaggi wrote:
> ACPI/IORT Support in Xen.
> --------------------------
>      Draft 2
>
> Revision History:
>
> Changes since v1-
> - Modified IORT Parsing data structures.
> - Added RID->StreamID and RID->DeviceID map as per Andre's suggestion.
> - Added reference code which can be read along with this document.
> - Removed domctl for DomU, it would be covered in PCI-PT design.
>
> Introduction:
> -------------
>
> I had sent out patch series [0] to hide smmu from Dom0 IORT.
> This document is a rework of the series as it:
> (a) extends scope by adding parsing of IORT table once
> and storing it in in-memory data structures, which can then be used
> for querying. This would eliminate the need to parse complete iort
> table multiple times.
>
> (b) Generation of IORT for domains be independent using a set of
> helper routines.
>
> Index
> --------
>
> 1. What is IORT. What are its components ?
> 2. Current Support in Xen
> 3. IORT for Dom0
> 4. IORT for DomU
> 5. Parsing of IORT in Xen
> 6. Generation of IORT
> 7. Implementation Phases
> 8. References
>
> 1. IORT Structure ?
> --------------------------------------------
> IORT refers to Input Output remapping table. It is essentially used to find
> information about the IO topology (PCIRC-SMMU-ITS) and relationships 
> between
> devices.
>
> A general structure of IORT [1]:
> It has nodes for PCI RC, SMMU, ITS and Platform devices. Using an IORT 
> table
> relationship between RID -> StreamID -> DeviceId can be obtained.
> Which device is behind which SMMU and which interrupt controller, topology
> is described in IORT Table.
>
> Some PCI RC may be not behind an SMMU, and directly map RID->DeviceID.
>
> RID is a requester ID in PCI context,
> StreamID is the ID of the device in SMMU context,
> DeviceID is the ID programmed in ITS.
>
> Each iort_node contains an ID map array to translate one ID into another.
> IDmap Entry {input_range, output_range, output_node_ref, id_count}
> This array is associated with PCI RC node, SMMU node, Named component node.
> and can reference to a SMMU or ITS node.
>
> 2. Current Support of IORT
> ---------------------------
> IORT is proposed to be used by Xen to setup SMMU's and platform devices
> and for translating RID->StreamID and RID->DeviceID.
I am not sure to understand "to setup SMMU's and platform devices...". 
With IORT, a software can discover list of SMMUs and the IDs to 
configure the ITS and SMMUs for each device (e.g PCI, integrated...) on 
the platform. You will not be able to discover the list of platform 
devices through it.
Also, it is not really "proposed". It is the only way to get those 
information from ACPI.
> It is proposed in this document to parse iort once and use the information
> to translate RID without traversing IORT again and again.
>
> Also Xen prepares an IORT table for dom0 based on host IORT.
> For DomU IORT table proposed only in case of device passthrough.
>
> 3. IORT for Dom0
> -----------------
> IORT for Dom0 is based on host iort. Few nodes could be removed or 
> modified.
>   For instance
> - Host SMMU nodes should not be present as Xen should only touch it.
> - platform nodes (named components) may be controlled by xen command line.
I am not sure where does this example come from? As I said, there are no 
plan to support Platform Device passthrough with ACPI. A better example 
here would removing PMCG.
> 4. IORT for DomU
> -----------------
> IORT for DomU should be generated by toolstack. IORT table is only present
> in case of device passthrough.
>
> At a minimum domU IORT should include a single PCIRC and ITS Group.
> Similar PCIRC can be added in DSDT.
> The exact structure of DomU IORT would be covered along with PCI PT design.
>
> 5. Parsing of IORT in Xen
> --------------------------
> IORT nodes can be saved in structures so that IORT table parsing can be 
> done
> once and is reused by all xen subsystems like ITS / SMMU etc, domain 
> creation.
> Proposed are the structures to hold IORT information. [4]
>
> struct rid_map_struct {
>      void *pcirc_node;
>      u16 ib; /* Input base */
>      u32 ob; /* Output base */
>      u16 idc; /* Id Count */
>       struct list_head entry;
> };
>
> struct iort_ref
> {
>      struct list_head rid_streamId_map;
>      struct list_head rid_deviceId_map;
> }iortref;
>
> 5.1 Functions to query StreamID and DeviceID from RID.
>
> void query_streamId(void *pcirc_node, u16 rid, u32 *streamId);
> void query_deviceId(void *pcirc_node, u16 rid, u32 *deviceId);
>
> Adding a mapping is done via helper functions
>
> intadd_rid_streamId_map(void*pcirc_node, u32 ib, u32 ob, u32 idc) 
> intadd_rid_deviceId_map(void*pcirc_node, u32 ib, u32 ob, u32 idc) - 
> rid-streamId map is straight forward and is created using pci_rc's idmap
> - rid-deviceId map is created by translating streamIds to deviceIds.
>      fixup_rid_deviceId_map function does that. (See [6])
>
> It is proposed that query functions should replace functions like
> iort_node_map_rid which is currently used in linux and is imported in Xen
> in the patchset [2][5]
>
> 5.2 Proposed Flow of parsing
> The flow is based on the patchset in [5]. I have added a reference code on
> top of it which does IORT parsing as described in this section. The code
> is available at [6].
>
> The commit also describes the code flow and assumptions.
Which assumptions? I can't see any in the commit message.

Cheers,

--
Julien Grall

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