Re: [Xen-devel] [PATCH 2/4] EFI/early: add /mapbs to map EfiBootServices{Code, Data}

[Roy Franz <roy.franz@xxxxxxxxxx>]

On Wed, Jun 10, 2015 at 2:37 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 10.06.15 at 11:26, <ian.campbell@xxxxxxxxxx> wrote:
>> On Wed, 2015-06-10 at 10:15 +0100, Jan Beulich wrote:
>>> >>> On 10.06.15 at 10:56, <ian.campbell@xxxxxxxxxx> wrote:
>>> > On Tue, 2015-06-09 at 14:53 +0100, Jan Beulich wrote:
>>> >> From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
>>> >>
>>> >> To help on certain platforms to run.
>>> >>
>>> >> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
>>> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>> >
>>> > To be effective (or at least consistent) on ARM, would we also want to
>>> > change its efi_process_memory_map_bootinfo:
>>> >         if ( desc_ptr->Type == EfiConventionalMemory
>>> >              || desc_ptr->Type == EfiBootServicesCode
>>> >              || desc_ptr->Type == EfiBootServicesData )
>>> > to include a check on map_bs?
>>>
>>> I'm not convinced, but I also don't know the history of why boot
>>> services areas are being included here in the first place - Roy?
>>> I.e. if the checks weren't there already, I'd agree that an addition
>>> similar to the other ones would be needed here, but with the x86
>>> side getting relaxed I don't see why you would want to tighten the
>>> ARM side at the same time.

The boot services code/data is "memory available for general use", just
like EfiConventionalMemory after ExitBootServices() is called.  Since the memory
map being created here is going to be used after ExitBootServices() is called,
I think this matches the UEFI specification. This matches x86 behavior before
the patch (modulo some address range checks used to set cfg.addr.)

>>
>> I read it backwards and thought this was currently excluding them like
>> x86 does.
>>
>> Am I correct that the stricter x86 behaviour is per the spec, and this
>> new option is a workaround for non-compliant systems?
>
> Yes.
>
>> If so unless Roy knows of a reason why these should be mapped on ARM be
>> default (i.e. the ARM spec differs) I'd be inclined to suggesting the
>> default be stricter on ARM too for consistency.
>
> I agree, but would want this to be a separate patch then in any event.
> I.e. I'm intending to commit the whole series shortly.
>
> Jan
>

The open question regarding the Arm code is whether we want/need this workaround
for Arm as well, right?  I don't see a reason why firmware bugs
regarding memory allocation
types would be x86 specific, so we could see firmware broken the same
way on arm platforms.
Is !map_bs the default?

I think "reserve_bs" would be a better name, as I think of it as being
'mapped' when it is added
as normal memory to the memory map.  I find the terminology in the
patch a bit generic/confusing.


Roy

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel