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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 10/06/15 18:22, Roy Franz wrote:
>
>>> 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.

It would be nice to hope that the arm side was all coded to spec. 
However, the realist in me would expect to see the same kinds of
mistakes on any architecture.

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

Technically, it is "map boot services code/data for runtime services",
as it is a workaround for firmware which doesn't correctly avoid using
__init/__initdata at runtime.

I don't agree that "reserve_bs" is any better, but can't think of a 3rd
alternative which would be better than either.

~Andrew

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