From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754011AbbIJLYh (ORCPT ); Thu, 10 Sep 2015 07:24:37 -0400 Received: from foss.arm.com ([217.140.101.70]:33552 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753541AbbIJLYc (ORCPT ); Thu, 10 Sep 2015 07:24:32 -0400 Date: Thu, 10 Sep 2015 12:24:19 +0100 From: Mark Rutland To: Stefano Stabellini Cc: 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" Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Message-ID: <20150910112418.GC29293@leverpostej> References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > Does Xen not talk to EFI itself and/or give the kernel a virtual EFI > > interface? > > Xen talks to EFI itself but the interface provided to dom0 is somewhat > different: there are no BootServices (Xen calls ExitBootServices before > running the kernel), and the RuntimeServices go via hypercalls (see > drivers/xen/efi.c). That's somewhat hideous; a non Xen-aware OS wouild presumably die if trying to use any runtime services the normal way? I'm not keen on describing things that the OS cannot use. Why can't Xen give a virtual EFI interface to Dom0 / guests? e.g. create pages of RuntimeServicesCode that are trivial assembly shims doing hypercalls, and plumb these into the virtual EFI memory map and tables? That would keep things sane for any guest, allow for easy addition of EFI features, and you could even enter the usual EFI entry point, simulate ExitBootServices(), SetVirtualAddressMap(), and allow the guest to make things sane for itself... Mark.