On 21.11.2022 17:48, Roger Pau Monné wrote:
> On Mon, Nov 21, 2022 at 05:27:16PM +0100, Jan Beulich wrote:
>> Hello,
>>
>> on a system with these first two EFI memory map entries
>>
>> (XEN) 0000000000000-000000009dfff type=4 attr=000000000000000f
>> (XEN) 000000009e000-000000009ffff type=2 attr=000000000000000f
>>
>> i.e. except for 2 pages all space below 1M being BootServicesData, the
>> -mapbs option has the effect of marking reserved all that space. Then
>> Linux fails trying to allocate its lowmem trampoline (which really it
>> shouldn't need when running in PV mode), ultimately leading to
>>
>> panic("Real mode trampoline was not allocated");
>>
>> in their init_real_mode().
>>
>> While for PV I think it is clear that the easiest is to avoid
>> trampoline setup in the first place, iirc PVH Dom0 also tries to
>> mirror the host memory map to its own address space. Does PVH Linux
>> require a lowmem trampoline?
>
> Yes, it does AFAIK. I guess those two pages won't be enough for
> Linux boot trampoline requirements then.
>
> I assume native Linux is fine with this memory map because it reclaims
> the EfiBootServicesData region and that's enough.
That's my understanding as well.
>> While the two pages here are just enough for Xen's trampoline, I still
>> wonder whether we want to adjust -mapbs behavior. Since whatever we
>> might do leaves a risk of conflicting with true firmware (mis)use of
>> that space, the best I can think of right now would be another option
>> altering behavior (or providing altered behavior). Yet such an option
>> would likely need to be more fine-grained then than covering all of
>> the low Mb in one go. Which feels like both going too far and making
>> it awkward for people to figure out what value(s) to use ...
>>
>> Thoughts anyone?
>
> I'm unsure what to recommend. The mapbs option is a workaround for
> broken firmware, and it's not enabled by default, so we might be lucky
> and never find a system with a memory map like you describe that also
> requires mapbs in order to boot.
Guess how we've learned of the issue: Systems may boot fine without
-mapbs, but they may fail to reboot because of that (in)famous issue of
firmware writers not properly separating boot services code paths from
runtime services ones. And there we're dealing with a system where I
suspect this to be the case, just that - unlike in earlier similar
cases - there's no "clean" crash proving the issue (the system simply
hangs). Hence my request that they use -mapbs to try to figure out.
And yes, "reboot=acpi" helps there, but they insist on knowing what
component is to blame.
Jan
> Any native OS would also have problems booting in such system if it
> has any option similar to mapbs, so I don't see much solution.
>
> Thanks, Roger.
