From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755395AbcASOM2 (ORCPT ); Tue, 19 Jan 2016 09:12:28 -0500 Received: from smtp02.citrix.com ([66.165.176.63]:38767 "EHLO SMTP02.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754623AbcASOMU (ORCPT ); Tue, 19 Jan 2016 09:12:20 -0500 X-IronPort-AV: E=Sophos;i="5.22,317,1449532800"; d="scan'208";a="332405628" Date: Tue, 19 Jan 2016 14:11:39 +0000 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Shannon Zhao CC: Mark Rutland , Stefano Stabellini , , , Shannon Zhao , , , , , , , , , , , , Jan Beulich , Ian Campbell Subject: Re: [PATCH v2 12/16] ARM: Xen: Document UEFI support on Xen ARM virtual platforms In-Reply-To: <569E3D9F.6050808@linaro.org> Message-ID: 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> <569E3D9F.6050808@linaro.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-DLP: MIA1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 19 Jan 2016, Shannon Zhao wrote: > 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 Ah! That patch is not upstream yet, that's why I thought that something was off. Listen to Shannon, don't listen to me :-)