[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [RFC] [Draft Design] ACPI/IORT Support in Xen.
On 10/31/2017 5:03 AM, Goel, Sameer wrote:
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.
The idea is parse one use at multiple places.
- IORT creation for Dom0
- smmu init
- finding smmu for a deviceID when pci_assign_device is called by dom0
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 :)).
Yes some of the parsing functions can be replaced with APIs.
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?
For all cases I believe where a mapping lookup of Devid-smmu-pcirc is
required.
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
