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

[Jan Beulich <jbeulich@xxxxxxxx>]

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"

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

Jan