Re: Xen 4.14.0 fails on Dell IoT Gateway without efi=no-rs

[Roman Shaposhnik <roman@xxxxxxxxxx>]

On Thu, Aug 20, 2020 at 11:47 PM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 20.08.2020 21:31, Roman Shaposhnik wrote:
> > On Thu, Aug 20, 2020 at 1:34 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
> >> On 20.08.2020 00:50, Roman Shaposhnik wrote:
> >>> (XEN) Unknown cachability for MFNs 0xff900-0xfffff
> >>
> >> The fault address falling in this range suggests you can use a less
> >> heavy workaround: "efi=attr=uc". (Quite possibly "efi=no-rs" or yet
> >> some other workaround may still be needed for your subsequent reboot
> >> hang.)
> >
> > I just tried and efi=attr=uc and it is, indeed, a workaround. I can get to
> > Dom0 booting far enough (and then I hit the other issue).
> >
> > However, since efi=attr=uc has always struck me as a bit of a hammer
> > still I tried the good ol':
> >      https://lists.archive.carbon60.com/xen/devel/408709
> >
> > And then Xen crashed in an interesting way (see below). Now, this
> > is with CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP -- so not sure
> > if it is related.
>
> Why "interesting way" - it's the same as before, you're
> hitting the range reported by "Unknown cachability for MFNs
> 0xff900-0xfffff"

It is interesting because it is a different call site -- that's what I'm after.

But you're right, of course, it fails because of the same range.

Why it is interesting to me -- see below.

> >> As far as making cases like this work by default, I'm afraid it'll
> >> need to be proposed to replace me as the maintainer of EFI code in
> >> Xen. I will remain on the position that it is not acceptable to
> >> apply workarounds for firmware issues by default unless they're
> >> entirely benign to spec-conforming systems. DMI data based enabling
> >> of workarounds, for example, is acceptable in the common case, as
> >> long as the matching pattern isn't unreasonably wide.
> >
> > Well, default is overloaded. What I would like to see (and consider it
> > a void of a small downstream/distro) is a community-agreed and
> > maintained way of working around these issues. Yes, I'd love to see
> > it working by default -- but if we can at least agree on an officially
> > supported knob that is less of a hammer than efi=attr=uc -- that'd
> > be a good first step.
> >
> > Makes sense?
>
> Sure, just that I don't see what less heavyweight alternatives
> to "efi=attr=uc" there are (short of supplying an option to
> provide per-range memory attributes, which would end up ugly
> to use). For the specific case here, "efi=attr=wp" could be
> made work, but might not be correct for all of the range (it's
> a EfiMemoryMappedIO range, after all); in the majority of cases
> of lacking attribute information that I've seen, UC was indeed
> what was needed.

I think we're talking slightly past each other here -- you seem to be
more after trying to figure out how to make this box look like a dozen
killobucks worth a server, I'm after trying to figure out what callsites
in Xen tickle that region.

I appreciate and respect your position, but please hear mine as well:
yes we're clearly into the "workaround" territory here, but clearly
Linux is fully capable of these workaround and I would like to understand
how expensive it will be to teach Xen those tricks as well.

Now, whether you'd accept these tricks upstream or not is an entirely
orthogonal question.

Thanks,
Roman.

P.S. And yes, ultimately, settling for efi=no-rs is what I did before
at least once.
So maybe shaving the callsite yak won't be that much fun after all.