From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934201AbcDLWMa (ORCPT ); Tue, 12 Apr 2016 18:12:30 -0400 Received: from mx2.suse.de ([195.135.220.15]:36840 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932353AbcDLWM2 (ORCPT ); Tue, 12 Apr 2016 18:12:28 -0400 Date: Wed, 13 Apr 2016 00:12:25 +0200 From: "Luis R. Rodriguez" To: "Luis R. Rodriguez" Cc: George Dunlap , Matt Fleming , Michael Chang , Julien Grall , Jan Beulich , "H. Peter Anvin" , Daniel Kiper , the arch/x86 maintainers , =?utf-8?Q?Vojt=C4=9Bch_Pavl=C3=ADk?= , Gary Lin , xen-devel , Jeffrey Cheung , Charles Arndol , Stefano Stabellini , Jim Fehlig , joeyli , Borislav Petkov , Boris Ostrovsky , Juergen Gross , Andrew Cooper , Linux Kernel Mailing List , Andy Lutomirski , David Vrabel , Roger Pau =?iso-8859-1?Q?Monn=E9?= , Takashi Iwai , jeffm@suse.com, torvalds@linux-foundation.org, Julien Grall Subject: Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry Message-ID: <20160412221225.GN1990@wotan.suse.de> References: <20160406024027.GX1990@wotan.suse.de> <20160407185148.GL1990@wotan.suse.de> <5707BD2E.20204@citrix.com> <20160408215854.GU1990@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160408215854.GU1990@wotan.suse.de> 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 On Fri, Apr 08, 2016 at 11:58:54PM +0200, Luis R. Rodriguez wrote: > On Fri, Apr 08, 2016 at 03:16:14PM +0100, George Dunlap wrote: > > On 07/04/16 19:51, Luis R. Rodriguez wrote: > > > While Andrew's position is right in that perhaps only Xen tools have to deal > > > with the HVMLite specific entry, it would also still mean diverging from ARM's > > > own EFI entry only position, which I'd like to clarify that ARM has no custom > > > Xen entry, we should strive to match that. Anything far from that to me really > > > deserves an explanation, specially if we are going to argue that HVMLite is > > > the best that x86 Xen can do. > > > > > > Ultimately unifying entry approaches for Xen in a streamlined fashion seems > > > like a sensible thing to strive for. Anything we push in the other direction, > > > as small as it can be, should deserve at least a 'hey, wait a minute'... > > > > Quick factual correction here. > > > > "Since ARM guests only use the EFI entry point, x86 guests should also > > only use the EFI entry point" is certainly a reasonable argument to make. > > > > However, dom0 on ARM does not use the EFI entry point. When starting > > dom0, Xen uses the native entry point (the one that UBoot uses) and > > hands dom0 a device-tree node. The reason this is possible on ARM is > > that there are no assumptions made about what hardware is or is not > > present on the system -- everything that needs to be communicated about > > what is or is not present can be passed in DT. > > > > So it is incorrect to say that ARM has an "EFI entry only" position. > > > > (On ACPI systems, it does apparently generate some UEFI informational > > tables, which it passes to the dom0 kernel via DT; and the kernel > > unpacks and puts in the right place. Normal Xen ARM guests can use EFI, > > but that's because we start OVMF in the guest context to provide the EFI > > services. These may be where the idea that ARM guests use only the UEFI > > entry point came from.) > > > > Obviously it would be nice if we could use the native entry point on x86 > > as well, but there's decades of legacy hardware and backwards > > compatibility to deal with there. > > OK thanks for the clarification -- still no custom entries for Xen! > We should strive for that, at the very least. > > You do have a point about the legacy stuff. There are two options there: > > * Fold legacy support under HVMLite -- which seems to be what we > currently want to do (we should evaluate the implications and > requirements here for that); or > > * Leave legacy stuff on the old PV path; this may be something to > bring to the table if we had in place a proactive solution to > avoid further fallout from the architecture of the huge differences > on the entries. The work I'm doing should help with that. (We should > also evaluate the implications and requirements here for that as > well). Also, x86 does have a history of short DT use. Just pointing that its there as an option as well. I'll Cc you on some thread about that. Luis