freebsd stable - Jun 2017 - EFI loader doesn't handle md_preload (md_image) correct?

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) ;-)
>
> So I'll stay with CSM for now, and will happily be an early adopter if
> you need someone to try anything (-stable mergable).
Toomas, thanks for your help so far! I'm just curious if there's news on
this.
Was there a decision made whether kernel should be utilized to relocate
the MD image modules or the loader should be extended to handle
(x-)large staging areas?

I'd like to switch back to UEFI booting for various reasons (most
priority has consistency), but can't since it breaks md-rootfs with that
machine (the other run ESXi still).

If there's anything to test, please let me know.

Thanks,

-harry

> On 29. juuni 2017, at 11:24, Harry Schmalzbauer <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)
;-)
>> 
>> So I'll stay with CSM for now, and will happily be an early adopter
if
>> you need someone to try anything (-stable mergable).
> 
> Toomas, thanks for your help so far! I'm just curious if there's
news on
> this.
> Was there a decision made whether kernel should be utilized to relocate
> the MD image modules or the loader should be extended to handle
> (x-)large staging areas?
> 
> I'd like to switch back to UEFI booting for various reasons (most
> priority has consistency), but can't since it breaks md-rootfs with
that
> machine (the other run ESXi still).
> 
> If there's anything to test, please let me know.
> 
> Thanks,
> 
> -harry
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.

rgds,
toomas