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

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

On Fri, Dec 21, 2018 at 01:13:25PM +0000, Andrew Cooper wrote:
> 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 :)

In this case it's my fault :(, because I changed the code and forgot
about the docs.

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

Oh yes, I didn't mean my comment to sound like criticism. I agree
there should be no issues in parsing the ELF earlier, or if there are
issues they should be fixed.

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

IIRC I've only found a single box that worked without map-reserved,
and that's my NUC which has firmware from Intel. And even in that case
the USB ports weren't fully working.

I guess such quirks could be applied based on the chipset version then
if Xen realizes the firmware is either wrong or missing obvious RMRR
regions?

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

Sadly I agree. What I'm worried about is turning the default
map-{inclusive/reserved} to off, that's likely to make dom0 unable to
boot on a huge amount of hardware.

Thanks, Roger.

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