From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH 2/4] EFI/early: add /mapbs to map EfiBootServices{Code, Data} Date: Wed, 10 Jun 2015 11:00:11 +0100 Message-ID: <1433930411.30003.24.camel@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 1Z2cny-0000RS-CY for xen-devel@lists.xenproject.org; Wed, 10 Jun 2015 10:00:18 +0000 In-Reply-To: <557821850200007800082F1F@mail.emea.novell.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: Jan Beulich Cc: roy.franz@linaro.org, xen-devel List-Id: xen-devel@lists.xenproject.org On Wed, 2015-06-10 at 10:37 +0100, Jan Beulich wrote: > >>> On 10.06.15 at 11:26, wrote: > > On Wed, 2015-06-10 at 10:15 +0100, Jan Beulich wrote: > >> >>> On 10.06.15 at 10:56, wrote: > >> > On Tue, 2015-06-09 at 14:53 +0100, Jan Beulich wrote: > >> >> From: Konrad Rzeszutek Wilk > >> >> > >> >> To help on certain platforms to run. > >> >> > >> >> Signed-off-by: Konrad Rzeszutek Wilk > >> >> Signed-off-by: Jan Beulich > >> > > >> > To be effective (or at least consistent) on ARM, would we also want to > >> > change its efi_process_memory_map_bootinfo: > >> > if ( desc_ptr->Type == EfiConventionalMemory > >> > || desc_ptr->Type == EfiBootServicesCode > >> > || desc_ptr->Type == EfiBootServicesData ) > >> > to include a check on map_bs? > >> > >> I'm not convinced, but I also don't know the history of why boot > >> services areas are being included here in the first place - Roy? > >> I.e. if the checks weren't there already, I'd agree that an addition > >> similar to the other ones would be needed here, but with the x86 > >> side getting relaxed I don't see why you would want to tighten the > >> ARM side at the same time. > > > > 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. Sure, lets wait and see what Roy says