[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 2:37 AM, Jan Beulich <JBeulich@xxxxxxxx> 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. The boot services code/data is "memory available for general use", just like EfiConventionalMemory after ExitBootServices() is called. Since the memory map being created here is going to be used after ExitBootServices() is called, I think this matches the UEFI specification. This matches x86 behavior before the patch (modulo some address range checks used to set cfg.addr.) >> >> 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. 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. Roy _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |