From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966124AbcDMJym (ORCPT ); Wed, 13 Apr 2016 05:54:42 -0400 Received: from smtp.citrix.com ([66.165.176.89]:57902 "EHLO SMTP.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965799AbcDMJyj (ORCPT ); Wed, 13 Apr 2016 05:54:39 -0400 X-IronPort-AV: E=Sophos;i="5.24,479,1454976000"; d="scan'208";a="346778961" Date: Wed, 13 Apr 2016 11:54:29 +0200 From: Roger Pau =?iso-8859-1?Q?Monn=E9?= 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" , Takashi Iwai , , , Julien Grall Subject: Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry Message-ID: <20160413095428.5mcbrimvc6vxffcw@mac> 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.6.0-neo (2016-04-07) X-DLP: MIA1 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 I'm not following here. What does it mean to fold legacy support under HVMlite? HVMlite doesn't have any legacy hardware, and that's the issue when it comes to using native Linux entry points. Linux might expect some legacy PC hardware to be always present, which is not true for HVMlite. Could you please clarify this point? > * 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). Classic PV guests don't have legacy hardware at all, they just have PV interfaces, so I'm even less sure of what this means. Roger.