Re: [Xen-devel] [PATCH 1/2] xen/dom0: Improve documentation for dom0= and dom0-iommu=

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Thu, Dec 20, 2018 at 11:40:51PM +0000, Andrew Cooper wrote:
> Update to the latest metadata style, and expand each of the clauses with more
> information, including applicable CONFIG_* options.
> 
> Drop the redundant comment beside parse_dom0_param(), to avoid it getting out
> of sync with the main documentation.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Thanks! A couple of fixes below, because the original text is actually
wrong...

> ---
> CC: Jan Beulich <JBeulich@xxxxxxxx>
> CC: Wei Liu <wei.liu2@xxxxxxxxxx>
> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> CC: Julien Grall <julien.grall@xxxxxxx>
> 
> Please double check for correctness.  The text matches my
> understanding/reading of the code, but some of it is rather subtle going.
> 
> It occurs to me that:
> 
>  * The choice of dom0 boot mode should in part be derived from the available
>    CONFIG_* options, and ELF notes advertised in the dom0 kernel.

This is indeed doable, but would require parsing the dom0 kernel
before building the domain.

> 
>  * AMD probably needs to gain an `ivmd=` to mirror `rmrr=` on the Intel side,
>    because we know there are other errors in the IVRS table.

Yes, albeit using rmrr is quite cumbersome because it's mostly a
trial-and-error process until there are no more iommu faults (unless
you can get the correct rmrr command for your hardware somewhere).

> 
>  * Neither of map-{inclusive,reserved} should be active by default, even on
>    Intel hardware, and we should (wherever possible) have quirks like we have
>    for all other firmware screwups.  Requiring the user to diagnose/work
>    around firmware problems like this is quite rude.

That would indeed be nice, but I think there are too many vendor
firmware versions to be able to correctly identify such quirks, the
more that vendors don't even list missing RMRR as erratum.

> +Controls for the dom0 IOMMU setup.
> +
> +*   The `passthrough` boolean is applicable to x86 PV dom0's only and 
> defaults
> +    to false.  It controls whether the IOMMU is fully disabled for devices
> +    belonging to dom0 (`passthrough=1`), or whether the IOMMU is set up with
> +    an identity transform for dom0 (`passthrough=0`) to prevent dom0 from
> +    DMA'ing outside of its permitted areas.
> +
> +    This option is hardwired to false for x86 PVH dom0's (where a 
> non-identity
> +    transform is required for dom0 to function), and is ignored for ARM.
> +
> +*   The `strict` boolean is applicable to x86 PV dom0's only and defaults to
> +    false.  It controls whether dom0 can have IOMMU mappings for all domain
> +    RAM in the system, or only for its allocated RAM (and grant mappings 
> etc.)
> +
> +    This option is hardwired to true for x86 PVH dom0's (as RAM belonging to
> +    other domains in the system don't live in a compatible address space), 
> and
> +    is ignored for ARM.
> +
> +*   The `map-inclusive` boolean is applicable to x86 PV dom0's, and sets up 
> DMA
> +    remapping for all non-RAM regions below 4GB except for unusable ranges.
> +
> +    Typically, some devices in a system use bits of RAM for communication, 
> and
> +    these areas should be listed via RMRR or IVMD entries in the APCI tables,
> +    so Xen can ensure that they are identity-mapped in the IOMMU.  However,
> +    some firmware makes mistakes writing its APCI tables, and this option is 
> a
> +    coarse-grain workaround for those errors.
> +
> +    Where possible, finer grain corrections should be made with the `rmrr=`,
> +    `ivrs_hpet=` or `ivrs_ioapic=` command line options.
> +
> +    This option is enabled by default on x86 Intel systems, disabled by
> +    default on other x86 systems, and invalid on ARM systems.

I'm afraid the previous text was wrong. I later discovered that AMD
also had such workarounds applied by default, and unified the code,
but failed to update the documentation, sorry.

map-inclusive is enabled by default on x86 for a PV dom0. See
xen/drivers/passthrough/x86/iommu.c:215 (arch_iommu_hwdom_init).

> +
> +*   The `map-reserved` functionality is very similar to `map-inclusive`, but 
> is
> +    applicable to both x86 PV and PVH dom0's, and represents a subset of the
> +    correction by only mapping reserved memory regions rather than all 
> non-RAM
> +    regions.
> +
> +    This option is enabled by default on x86 Intel systems, disabled by
> +    default on other x86 systems, and invalid on ARM systems.

map-reserved is enabled by default on x86,
xen/drivers/passthrough/x86/iommu.c:218 (arch_iommu_hwdom_init).

The text itself looks OK to me.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel