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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 21/12/2018 12:08, Roger Pau Monné wrote:
> 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...

TBH, that is my default assumption every time I do work like this :)

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

I don't see anything wrong with parsing the ELF headers ahead of
building the domain.  From the overall boot time, its just an
order-of-operations issue.

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

I don't agree.  We already have quirks based on DMI (at the moment,
mainly for reboot overrides), and the vast majority of the offending
cases are the BMC shared mailbox, which will be in a fixed per-platform
location.

I don't expect we'll ever find and fix all quirks, but where we do find
suitable ones, we should put them into the boot code.

>
>> +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).

Ok for both.  Will fix up.

~Andrew

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