EFI loader doesn't handle md_preload (md_image) correct?

[Harry Schmalzbauer]

Bezüglich Toomas Soome's Nachricht vom 29.06.2017 10:39 (localtime):
> 
>> On 29. juuni 2017, at 11:24, Harry Schmalzbauer <freebsd at omnilan.de
>> <mailto:freebsd at omnilan.de>> wrote:
>>
>> Bezüglich Harry Schmalzbauer's Nachricht vom 16.05.2017 18:26 (localtime):
>>> B
>> …
>>>>>> The issue is, that current UEFI implementation is using 64MB staging
>>>>>> memory for loading the kernel and modules and files. When the boot is
>>>>>> called, the relocation code will put the bits from staging area
>>>>>> into the
>>>>>> final places. The BIOS version does not need such staging area,
>>>>>> and that
>>>>>> will explain the difference.
>>>>>>
>>>>>> I actually have different implementation to address the same problem,
>>>>>> but thats for illumos case, and will need some work to make it usable
>>>>>> for freebsd; the idea is actually simple - allocate staging area per
>>>>>> loaded file and relocate the bits into the place by component, not as
>>>>>> continuous large chunk (this would also allow to avoid the mines like
>>>>>> planted by hyperv;), but right now there is no very quick real
>>>>>> solution
>>>>>> other than just build efi loader with larger staging size.
>>>>> Ic, thanks for the explanation.
>>>>> While not aware about the purpose of the staging area nor the
>>>>> consequences of enlarging it, do you think it's feasable increasing it
>>>>> to 768Mib?
>>>>>
>>>>> At least now I have an idea baout the issue and an explanation why
>>>>> reducing md_imgae to 100MB hasn't helped – still more than 64...
>>>>>
>>>>> Any quick hint where to define the staging area size highly
>>>>> appreciated,
>>>>> fi there are no hard objections against a 768MB size.
>>>>>
>>>>> -harry
>>>> The problem is that before UEFI Boot Services are not switched off,
>>>> the memory is managed (and owned) by the firmware,
>>> Hmm, I've been expecting something like that (owend by firmware) ;-)
>>>

…

> There has not been too much activities about this topic, except some
> discussions. But it is quite clear that this change has to be handled by
> the loader in first place - as we need to get the data in safe location;
> now of course there is secondary part as well - it may be that kernel
> would need some work as well, depending on how the md image(s) are to be
> handled in relation to memory maps.

Hello Toomas,

unfortunately my skills don't allow me to make this happen myself :-(
But since almost every production system here is MFS_ROOT based, I'm
awfully missing the UEFI boot feature, especially on those where I have
to do work via vt(4) from time to time, which would be a lot easier if
vt_efi was usable instead of vt_vga :-)

Can you estimate if someone has intentions/interest/time to implement
the missing extensions in boot and kernel resp. the timeframe?

Thanks,

-harry