From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755367AbcASNoF (ORCPT ); Tue, 19 Jan 2016 08:44:05 -0500 Received: from mail-pf0-f175.google.com ([209.85.192.175]:32773 "EHLO mail-pf0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754992AbcASNnz (ORCPT ); Tue, 19 Jan 2016 08:43:55 -0500 Message-ID: <569E3D9F.6050808@linaro.org> Date: Tue, 19 Jan 2016 21:43:59 +0800 From: Shannon Zhao User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mark Rutland , Stefano Stabellini , ard.biesheuvel@linaro.org, leif.lindholm@linaro.org CC: Shannon Zhao , linux-arm-kernel@lists.infradead.org, stefano.stabellini@citrix.com, david.vrabel@citrix.com, catalin.marinas@arm.com, will.deacon@arm.com, julien.grall@citrix.com, xen-devel@lists.xen.org, devicetree@vger.kernel.org, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, peter.huangpeng@huawei.com, Jan Beulich , Ian Campbell Subject: Re: [PATCH v2 12/16] ARM: Xen: Document UEFI support on Xen ARM virtual platforms References: <1452840929-19612-1-git-send-email-zhaoshenglong@huawei.com> <1452840929-19612-13-git-send-email-zhaoshenglong@huawei.com> <20160118105115.GD21067@leverpostej> <569E0F15.8090001@huawei.com> <20160119104747.GB25024@leverpostej> <20160119131348.GJ25024@leverpostej> In-Reply-To: <20160119131348.GJ25024@leverpostej> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/1/19 21:13, Mark Rutland wrote: > On Tue, Jan 19, 2016 at 12:23:17PM +0000, Stefano Stabellini wrote: >> >On Tue, 19 Jan 2016, Mark Rutland wrote: >>> > >On Tue, Jan 19, 2016 at 06:25:25PM +0800, Shannon Zhao wrote: >>>>>> > > > >>We don't do this in Documentation/arm/uefi.txt, and I don't see why we >>>>>> > > > >>should do so here. >>>>>> > > > >> >>>>>> > > > >>Does Xen handle arbitrary size memory map descriptors? I'm not sure what >>>>>> > > > >>new information might be passed in future additions to the descriptor >>>>>> > > > >>format, and I'm not sure what should happen in the Dom0 case. >>>>> > > > > >>>>> > > > >Xen passes to Dom0 the memory map in the same format as the native >>>>> > > > >memory map. >>> > > >>> > >Does Xen parse or modify the EFI memory map in any way? >> > >> >Xen: >> >- calls EFI_BOOT_SERVICES.GetMemoryMap() >> >- takes note of the memory regions for its own usage >> >- create the fdt notes, including efi-mmap-start, with a pointer to it >> > >> > >>> > >Does it pass the raw values returned by EFI_BOOT_SERVICES.GetMemoryMap() >>> > >through to the xen,uefi-* properties, or does is make any static >>> > >assumptions about what the values will be? >> > >> >It just passes the raw values. > I take it that means that any memory carved out for Xen itself is > described/discovered via a separate mechanism? How does that work For Xen hypervisor booting on UEFI, it get the EFI memory map through the similar way like Linux, e.g. call EFI_BOOT_SERVICES.GetMemoryMap(). For Dom0, Xen will create a new EFI memory map for Dom0. See [PATCH v3 52/62] arm/acpi: Prepare EFI memory descriptor for Dom0 http://lists.xen.org/archives/html/xen-devel/2015-11/msg01884.html Thanks, -- Shannon