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

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

On 10/12/2017 3:03 PM, Manish Jaggi wrote:
> ACPI/IORT Support in Xen.
> --------------------------------------
> 
> I had sent out patch series [0] to hide smmu from Dom0 IORT. Extending the 
> scope
> and including all that is required to support ACPI/IORT in Xen. Presenting 
> for review
> first _draft_ of design of ACPI/IORT support in Xen. Not complete though.
> 
> Discussed is the parsing and generation of IORT table for Dom0 and DomUs.
> It is proposed that IORT be parsed and the information in saved into xen 
> data-structure
> say host_iort_struct and is reused by all xen subsystems like ITS / SMMU etc.
> 
> Since this is first draft is open to technical comments, modifications
> and suggestions. Please be open and feel free to add any missing points / 
> additions.
> 
> 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. Future Work and TODOs
> 
> 1. What is IORT. What are its components ?
> --------------------------------------------
> 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 is has nodes which have information about PCI RC,
> SMMU, ITS and Platform devices. Using an IORT table relationship between
> RID -> StreamID -> DeviceId can be obtained. More specifically which device is
> behind which SMMU and which interrupt controller, this topology is described 
> in
> IORT Table.
> 
> 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.
> 
> For a non-pci device RID could be simply an ID.
> 
> Each iort_node contains an ID map array to translate from one ID into another.
> IDmap Entry {input_range, output_range, output_node_ref, id_count}
> This array is present in PCI RC node,SMMU node, Named component node etc
> and can reference to a SMMU or ITS node.
> 
> 2. Current Support of IORT
> ---------------------------
> Currently Xen passes host IORT table to dom0 without any modifications.
> For DomU no IORT table is passed.
> 
> 3. IORT for Dom0
> -----------------
> IORT for Dom0 is prepared by xen and it is fairly similar to the host iort.
> However few nodes could be removed removed or modified. For instance
> - host SMMU nodes should not be present
> - ITS group nodes are same as host iort but, no stage2 mapping is done for 
> them.
> - platform nodes (named components) may be selectively present depending on 
> the
> case where xen is using some. This could be controlled by  xen command line.
> - More items : TODO
> 
> 4. IORT for DomU
> ---------------
 
> IORT for DomU is generated by the toolstack. IORT topology is different when
> DomU supports device passthrough.
> 
> At a minimum domU IORT should include a single PCIRC and ITS Group.
> Similar PCIRC can be added in DSDT.
> Additional node can be added if platform device is assigned to domU.
> No extra node should be required for PCI device pass-through.
> 
> It is proposed that the idrange of PCIRC and ITS group be constant for domUs.
> In case if PCI PT,using a domctl toolstack can communicate
> physical RID: virtual RID, deviceID: virtual deviceID to xen.
> 
> It is assumed that domU PCI Config access would be trapped in Xen. The RID at
> which assigned device is enumerated would be the one provided by the domctl,
> domctl_set_deviceid_mapping
> 
> TODO: device assign domctl i/f.
> 
> Note: This should suffice the virtual deviceID support pointed by Andre. [4]
> We might not need this domctl if assign_device hypercall is extended to 
> provide this information.
> 
> 5. Parsing of IORT in Xen
> --------------------------
I think a Linux like approach will solve the following use cases:
1. Identify the SMMU devices and initialize the devices as needed.
2. API function to setup SMMUs in response to a discovery notification from DOM0
   - We will still need a path for non pcie devices.
   - I agree with Andre that the use cases for the named nodes in IORT should 
be treated the same as PCIe RC devices.
3. The concept of fwnode is still valid as per 4.14 and we can try reuse most 
of the parsing code.

Manish, I looked at your old patch and had a couple of questions before I 
comment more on this design. From an initial 
glance, it seems that you should be able to hide SMMUs by calling the already 
defined API functions in the iort.c implementation
(for most part :)). 

I am wondering if we really need to keep a list of parsed nodes. Or which use 
case apart from hw dom IORT mandates this?

> 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, very similar to ACPI
> structures.
> 
> iort_id_map {
>     range_t input_range;
>     range_t output_range;
>     void *output_reference;
> ...
> }
> =>output_reference points to object of iort_node.
> 
> struct iort_node {
>     struct list_head id_map;
>     void *context;
>     struct list_head list;
> }
> => context could be a reference to acpi_iort_node.
> 
> struct iort_table_struct {
>     struct list_head pci_rc_nodes;
>     struct list_head smmu_nodes;
>     struct list_head plat_devices;
>     struct list_head its_group;
> }
> 
> This structure is created at the point IORT table is parsed say from 
> acpi_iort_init.
> It is proposed to use this structure information in 
> iort_init_platform_devices.
> [2] [RFC v2 4/7] ACPI: arm: Support for IORT
> 
> 6. IORT Generation
> -------------------
> There would be a common code to generate IORT table from iort_table_struct.
> 
> a. For Dom0
>     the structure (iort_table_struct) be modified to remove smmu nodes
>     and update id_mappings.
>     PCIRC idmap -> output refrence to ITS group.
>     (RID -> DeviceID).
> 
>     TODO: Describe algo in update_id_mapping function to map RID -> DeviceID 
> used
>     in my earlier patch [3]
> 
> b. For DomU
>     - iort_table_struct would have minimal 2 nodes (1 PCIRC and 1 ITS group)
>     - populate a basic IORT in a buffer passed by toolstack( using a domctl : 
> domctl_prepare_dom_iort)
> 
>     - DSDT for the DomU is updated by toolstack to include a PCIRC.
>     - If a named component is added to domU that information is passed in the
>     same/additional domctl.
>         - <TODO: domctl_prepare_dom_iort i/f >
>     Note: Julien I have tried to incorporate your suggestion for code reuse.
> 
> 7. References:
> -------------
> [0] https://www.mail-archive.com/xen-devel@xxxxxxxxxxxxx/msg121667.html
> [1] ARM DEN0049C: 
> http://infocenter.arm.com/help/topic/com.arm.doc.den0049c/DEN0049C_IO_Remapping_Table.pdf
> [2] https://www.mail-archive.com/xen-devel@xxxxxxxxxxxxx/msg123082.html
> [3] https://www.mail-archive.com/xen-devel@xxxxxxxxxxxxx/msg121669.html: 
> update_id_mapping function.
> [4] https://www.mail-archive.com/xen-devel@xxxxxxxxxxxxx/msg123434.html
> 
> 
> 
> _______________________________________________
> 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