Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753550AbcDFPCp (ORCPT ); Wed, 6 Apr 2016 11:02:45 -0400 Received: from mail-wm0-f41.google.com ([74.125.82.41]:38144 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753215AbcDFPCn (ORCPT ); Wed, 6 Apr 2016 11:02:43 -0400 Date: Wed, 6 Apr 2016 16:02:40 +0100 From: Matt Fleming To: George Dunlap Cc: "Luis R. Rodriguez" , Andrew Cooper , Boris Ostrovsky , David Vrabel , Roger Pau =?iso-8859-1?Q?Monn=E9?= , Juergen Gross , Charles Arndol , Jim Fehlig , Jan Beulich , Daniel Kiper , "H. Peter Anvin" , the arch/x86 maintainers , Stefano Stabellini , Linux Kernel Mailing List , Michael Chang , Andy Lutomirski , joeyli , Julien Grall , =?utf-8?Q?Vojt=C4=9Bch_Pavl=C3=ADk?= , Borislav Petkov , xen-devel , Gary Lin , Jeffrey Cheung Subject: Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry Message-ID: <20160406150240.GO2701@codeblueprint.co.uk> References: <20160406024027.GX1990@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24+41 (02bc14ed1569) (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2258 Lines: 49 On Wed, 06 Apr, at 12:07:36PM, George Dunlap wrote: > > So rather than make a new entry point which does just the minimal > amount of work to run on a software interface (Xen), you want to take > an interface designed for hardware (EFI) and put in hacks so that it > knows that sometimes some EFI services are not available? That sounds > like it's going to make the EFI path just as unmanageable as the > current PV path. Requiring code in the new entry point to manipulate control registers and do the switch to long-mode does not seem like a minimal amount of code to me, http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg00134.html What's likely to happen in the future is that startup_(32|64) will be entered with different settings depending on whether coming from HVMlite or bare metal, due to the natural tendency for these kinds of code paths to diverge. Sometimes EFI runtime services are not available on bare metal hardware too, for example, when booting 32-bit kernels on 64-bit EFI or 64-bit kernels on 32-bit EFI without CONFIG_EFI_MIXED. Or when booting with the "noefi" kernel command line parameter. That's how things work today when booting Xen, we disable the runtime services. EFI boot services are a different story however, and the EFI boot stub would need to be changed to handle that. Though honestly, it would make more sense to provide EFI services stubs in the kernel image itself that are implemented using hypercalls, and assuming you can run hypercalls that early in boot. One place that struck me as suitable for this "hypercall in an EFI service stub" approach is the trouble with doing ACPI reboot as documented here, http://lists.xen.org/archives/html/xen-devel/2016-02/msg01609.html Performing the reset hypercall from within HVMlite's custom EfiReset() service would avoid having to touch ACPICA at all, and would be indistinguishable from bare metal. > Using the EFI entry point would certainly make sense if it was > actually simpler than the proposed extra entry point. But it sounds > like it's going to be more complicated, not only for Xen, but also for > Linux. Until someone sits down and writes the code I think we're going to be arguing back and forth over this particular point.