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

[Manish Jaggi <mjaggi@xxxxxxxxxxxxxxxxxx>]

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
--------------------------
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