From owner-freebsd-arm@freebsd.org Fri Sep 11 12:47:02 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 C1930A01ACB for ; Fri, 11 Sep 2015 12:47:02 +0000 (UTC) (envelope-from daniel.kiper@oracle.com) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "userp1040.oracle.com", Issuer "VeriSign Class 3 International Server CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 895A51DCA for ; Fri, 11 Sep 2015 12:47:02 +0000 (UTC) (envelope-from daniel.kiper@oracle.com) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8BCkphw019886 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Sep 2015 12:46:51 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t8BCkoWs005102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Sep 2015 12:46:50 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t8BCkoQH027033; Fri, 11 Sep 2015 12:46:50 GMT Received: from olila.local.net-space.pl (/10.175.171.201) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 Sep 2015 05:46:50 -0700 Date: Fri, 11 Sep 2015 14:46:43 +0200 From: Daniel Kiper To: Mark Rutland Cc: Stefano Stabellini , Shannon Zhao , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-efi@vger.kernel.org" , "Ian.Campbell@citrix.com" , "linux-doc@vger.kernel.org" , "ard.biesheuvel@linaro.org" , "linux-kernel@vger.kernel.org" , "leif.lindholm@linaro.org" , "xen-devel@lists.xen.org" , "julien.grall@citrix.com" , "freebsd-arm@freebsd.org" , "matt.fleming@intel.com" , "christoffer.dall@linaro.org" , "jbeulich@suse.com" , "peter.huangpeng@huawei.com" , "shannon.zhao@linaro.org" , Konrad Rzeszutek Wilk Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Message-ID: <20150911124643.GB4530@olila.local.net-space.pl> References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> <20150910112418.GC29293@leverpostej> <20150910121514.GE29293@leverpostej> <20150910144938.GI29293@leverpostej> <20150910162302.GN29293@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910162302.GN29293@leverpostej> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-Mailman-Approved-At: Fri, 11 Sep 2015 14:54:36 +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: Fri, 11 Sep 2015 12:47:02 -0000 On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote: > > > C) When you could go: > > > > > > DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI discovery > > > > I take you mean discovering Xen with the usual Xen hypervisor node on > > device tree. I think that C) is a good option actually. I like it. Not > > sure why we didn't think about this earlier. Is there anything EFI or > > ACPI which is needed before Xen support is discovered by > > arch/arm64/kernel/setup.c:setup_arch -> xen_early_init()? > > Currently lots (including the memory map). With the stuff to support > SPCR, the ACPI discovery would be moved before xen_early_init(). > > > If not, we could just go for this. A lot of complexity would go away. > > I suspect this would still be fairly complex, but would at least prevent > the Xen-specific EFI handling from adversely affecting the native case. > > > > D) If you want to be generic: > > > EFI -> EFI application -> EFI tables -> ACPI tables -> Xen-specific stuff > > > \------------------------------------------/ > > > (virtualize these, provide shims to Dom0, but handle > > > everything in Xen itself) > > > > I think that this is good in theory but could turn out to be a lot of > > work in practice. We could probably virtualize the RuntimeServices but > > the BootServices are troublesome. > > 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? What do you need from EFI boot services in dom0? Daniel