From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH 2/4] EFI/early: add /mapbs to map EfiBootServices{Code, Data} Date: Wed, 10 Jun 2015 15:48:15 -0400 Message-ID: <20150610194815.GA5109@l.oracle.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> <55787DF7.9020100@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z2lzA-0000Ld-KU for xen-devel@lists.xenproject.org; Wed, 10 Jun 2015 19:48:28 +0000 Content-Disposition: inline In-Reply-To: <55787DF7.9020100@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: Roy Franz , xen-devel , Ian Campbell , Jan Beulich List-Id: xen-devel@lists.xenproject.org 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 ? > ~Andrew > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel