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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Wed, Jun 10, 2015 at 07:12:07PM +0100, Andrew Cooper 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.
> 

fix_bs ?

<chuckles>
> ~Andrew
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

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