[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, 2015-06-10 at 11:00 +0100, Ian Campbell wrote:
> On Wed, 2015-06-10 at 10:37 +0100, Jan Beulich wrote:
> > >>> On 10.06.15 at 11:26, <ian.campbell@xxxxxxxxxx> wrote:
> > > On Wed, 2015-06-10 at 10:15 +0100, Jan Beulich wrote:
> > >> >>> On 10.06.15 at 10:56, <ian.campbell@xxxxxxxxxx> wrote:
> > >> > On Tue, 2015-06-09 at 14:53 +0100, Jan Beulich wrote:
> > >> >> From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> > >> >> 
> > >> >> To help on certain platforms to run.
> > >> >> 
> > >> >> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> > >> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> > >> > 
> > >> > 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

... before doing anything more than committing the whole series I mean.
Sorry for being vague!





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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.