From owner-freebsd-arm@freebsd.org Mon Sep 14 09:25:47 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82CF8A039DC for ; Mon, 14 Sep 2015 09:25:47 +0000 (UTC) (envelope-from mark.rutland@arm.com) Received: from foss.arm.com (foss.arm.com [217.140.101.70]) by mx1.freebsd.org (Postfix) with ESMTP id 6248B17FC for ; Mon, 14 Sep 2015 09:25:46 +0000 (UTC) (envelope-from mark.rutland@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id ECC6675; Mon, 14 Sep 2015 02:25:53 -0700 (PDT) Received: from leverpostej (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6CCEA3F318; Mon, 14 Sep 2015 02:25:34 -0700 (PDT) Date: Mon, 14 Sep 2015 10:25:19 +0100 From: Mark Rutland To: Daniel Kiper Cc: "devicetree@vger.kernel.org" , "linux-efi@vger.kernel.org" , "Ian.Campbell@citrix.com" , Konrad Rzeszutek Wilk , Stefano Stabellini , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "leif.lindholm@linaro.org" , "xen-devel@lists.xen.org" , "ard.biesheuvel@linaro.org" , "freebsd-arm@freebsd.org" , "matt.fleming@intel.com" , "christoffer.dall@linaro.org" , "jbeulich@suse.com" , Shannon Zhao , "julien.grall@citrix.com" , "peter.huangpeng@huawei.com" , "linux-arm-kernel@lists.infradead.org" , "shannon.zhao@linaro.org" Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Message-ID: <20150914092518.GA10307@leverpostej> References: <20150910112418.GC29293@leverpostej> <20150910121514.GE29293@leverpostej> <20150910144938.GI29293@leverpostej> <20150910162302.GN29293@leverpostej> <20150911124643.GB4530@olila.local.net-space.pl> <20150911162559.GA8726@leverpostej> <20150912113655.GG4530@olila.local.net-space.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150912113655.GG4530@olila.local.net-space.pl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Mon, 14 Sep 2015 11:22:17 +0000 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 09:25:47 -0000 On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel Kiper wrote: > On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote: > > On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote: > > > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote: > > [...] > > > > > What's troublesome with the boot services? > > > > > > > > What can't be simulated? > > > > > > How do you want to access bare metal EFI boot services from dom0 if they > > > were shutdown long time ago before loading dom0 image? > > > > I don't want to. > > > > I asked "What can't be simulated?" because I assumed everything > > necessary/mandatory could be simulated without needinng access to any > > real EFI boot services. > > > > As far as I can see all that's necessary is to provide a compatible > > interface. > > Could you be more precise what do you need? Please enumerate. UEFI spec has > more than 2500 pages and I do not think that we need all stuff in dom0. > > > > What do you need from EFI boot services in dom0? > > > > The ability to call ExitBootServices() and SetVirtualAddressMap() on a > > _virtual_ address map for _virtual_ services provided by the hypervisor. > > I am confused. Why do you need that? Please remember, EFI is owned and > operated by Xen hypervisor. dom0 does not have direct access to EFI. Let's take a step back. My objection here is to passing the Dom0 kernel properties as if it were booted with direct access to a full UEFI, then later fixing that up (when Xen is detected and we apply its hypercall EFI implementation). If the kernel cannot use EFI natively, why pretend to the kernel that it can? The hypercall implementation is _not_ EFI (though it provides access to some services). The two ways I can see providing Dom0 with EFI services are: * Have Xen create shims for any services, in which any hypercalls live, and pass these to the kernel with a virtual system table. This keeps the interface to the kernel the same regardless of Xen. * Have the kernel detect Xen EFI capability via Xen, without passing the usual native EFI parameters. This can then be installed into the kernel in a Xen-specific manner, and we know from the outset that Xen-specific caveats apply. As per my original email, I'm not against the renaming of the stub parameters if we standardise the rest of the details, but I believe that's orthogonal to the Xen Dom0 case. Thanks, Mark.