From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 2/4] EFI/early: add /mapbs to map EfiBootServices{Code, Data} Date: Wed, 10 Jun 2015 19:12:07 +0100 Message-ID: <55787DF7.9020100@citrix.com> References: <55770B190200007800082A2C@mail.emea.novell.com> <55770BDF0200007800082A43@mail.emea.novell.com> <1433926580.30003.4.camel@citrix.com> <55781C570200007800082F01@mail.emea.novell.com> <1433928364.30003.21.camel@citrix.com> <557821850200007800082F1F@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z2lNW-0005u7-Cp for xen-devel@lists.xenproject.org; Wed, 10 Jun 2015 19:09:34 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Roy Franz , Jan Beulich Cc: xen-devel , Ian Campbell List-Id: xen-devel@lists.xenproject.org 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