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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 21.08.2020 09:38, Roman Shaposhnik wrote:
> On Thu, Aug 20, 2020 at 11:47 PM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>> On 20.08.2020 21:31, Roman Shaposhnik wrote:
>>> 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.

What I'm trying is to understand what exactly is wrong in the firmware,
as that'll likely allow determining a minimal workaround. Figuring out
the call sites is certainly also an approach, but the stack trace
provided isn't enough for doing so, I'm afraid. Even the raw hex stack
dump contains only two pointers into Xen's .text, and to figure what
they represent one would need the xen.efi that was used. Possibly even
a deeper stack dump might be needed.

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

My prime example here is their blanket avoiding of the time related
runtime services, despite the EFI spec saying the exact opposite.
"efi=no-rs" is just a wider scope workaround of this same kind. The
reasoning I see behind this is that if the time related runtime
services are problematic, how likely is it that others are fine to
use? And how would an admin know without first having run into some
crash? If there are fair reasons to have finer grained disabling of
runtime services - why not? But it'll still take a command line
option to do so, unless (as was proposed) a build-time option of
enabling all (common?) workarounds by default gets made use of.

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

Well, I'd say "separate", not "orthogonal", because the nature of
such workarounds qualifies (to me) what is or is not acceptable as
default behavior.

Jan