[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/4] EFI/early: add /mapbs to map EfiBootServices{Code, Data}
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |