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 11:12 AM, Andrew Cooper
<andrew.cooper3@xxxxxxxxxx> wrote:
> 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.

OK, makes sense.  I was focusing on it getting marked as E820_reserved,
and missed the later mapping with runtime services.  I agree that reserve_bs
is not better.  I won't bikeshed any further :)

>
> ~Andrew

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