Re: [PATCH v2 0/2] ARM: ACPI: IORT: Hide SMMU from hardware domain's IORT table

[Andre Przywara <andre.przywara@arm.com>]

Hi Manish,

On 11/09/17 22:33, mjaggi@caviumnetworks.com wrote:
> From: Manish Jaggi <mjaggi@cavium.com>
> 
> The set is divided into two patches. First one calculates the size of IORT
> while second one writes the IORT table itself.

It would be good if you could give a quick introduction *why* this set
is needed here (and introduce IORT to the casual reader).
In general some more high-level documentation on your functions would be
good, as it took me quite some time to understand what each function does.

So my understanding is:
phase 1:
- go over each entry in each RC node
-   if that points to an SMMU node, go over each outgoing ITS entry and
find overlaps with this RC entry
-     for each overlap create a new entry in a list with this RC
pointing to the ITS directly

phase 2, creating the new IORT
- go over each RC node
-   if that points to an ITS, copy through IORT entries
-   if that points to an SMMU, replace with the remapped entries
- go over each ITS node
-   copy through IORT entries

So I believe this would do the trick and you end up with an efficient
representation of the IORT without SMMUs - at least for RC nodes.

After some brainstorming with Julien we found two problems:
1) This only covers RC nodes, but not "named components" (platform
devices), which we will need. That should be fixable by removing the
hardcoded IORT node types in the code and treating NC nodes like RC nodes.
2) Eventually we will need *virtual* deviceID support, for DomUs. Now we
could start introducing that already, also doing some virtual mapping
for Dom0. The ITS code would then translate each virtual device ID that
Dom0 requests into a hardware device ID.
I agree that this means a lot more work, but we will need it anyway.

I think 1) can be solved using this series as a base. I have quite some
comments ready for the patches, shall we follow this route.

2) obviously would change the game completely. We need to sit down and
design this properly. Probably this means that Xen parses the IORT and
builds internal representations of the mappings, which are consulted as
needed when passing through devices. The guest's (that would include
Dom0) IORT would then be generated completely from scratch.

I would like to hear your opinion on this. I will try to discuss the
feasibility of 2) with people at Connect. It would be good if we could
decide whether this is the way to go or we should use a solution based
on this series.

Cheers,
Andre.


> patch1: estimates size of hardware domain IORT table by parsing all
> the pcirc nodes and their idmaps, and thereby calculating size by
> removing smmu nodes.
> 
> Hardware domain IORT table will have only ITS and PCIRC nodes, and PCIRC
> nodes' idmap will have output refrences to ITS group nodes.
> 
> patch 2: The steps are:
> a. First ITS group nodes are written and their offsets are saved
> along with the respective offsets from the firmware table.
> This is required when smmu node is hidden and smmu node still points
> to the old output_reference.
> 
> b. PCIRC idmap is parsed and a list of idmaps is created which will
> have PCIRC idmap -> ITS group nodes.
> Each idmap is written by resolving ITS offset from the map saved in
> previous step.
> 
> Changes wrt v1:
> No assumption is made wrt format of IORT / hw support
> 
> Manish Jaggi (2):
>   ARM: ACPI: IORT: Estimate the size of hardware domain IORT table
>   ARM: ACPI: IORT: Write Hardware domain's IORT table
> 
>  xen/arch/arm/acpi/Makefile  |   1 +
>  xen/arch/arm/acpi/iort.c    | 414 ++++++++++++++++++++++++++++++++++++++++++++
>  xen/arch/arm/domain_build.c |  49 +++++-
>  xen/include/asm-arm/acpi.h  |   1 +
>  xen/include/asm-arm/iort.h  |  17 ++
>  5 files changed, 481 insertions(+), 1 deletion(-)
>  create mode 100644 xen/arch/arm/acpi/iort.c
>  create mode 100644 xen/include/asm-arm/iort.h
> 

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