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.coop...@citrix.com>
> 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 <jbeul...@suse.com>
>> CC: Wei Liu <wei.l...@citrix.com>
>> CC: Roger Pau Monné <roger....@citrix.com>
>> CC: Stefano Stabellini <sstabell...@kernel.org>
>> CC: Julien Grall <julien.gr...@arm.com>
>>
>> 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
