Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932068AbcDMSuO (ORCPT ); Wed, 13 Apr 2016 14:50:14 -0400 Received: from mx2.suse.de ([195.135.220.15]:33291 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755329AbcDMSuM (ORCPT ); Wed, 13 Apr 2016 14:50:12 -0400 Date: Wed, 13 Apr 2016 20:50:10 +0200 From: "Luis R. Rodriguez" To: Roger Pau =?iso-8859-1?Q?Monn=E9?= Cc: "Luis R. Rodriguez" , 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 , jeffm@suse.com, torvalds@linux-foundation.org, Julien Grall Subject: Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry Message-ID: <20160413185010.GX1990@wotan.suse.de> References: <20160406024027.GX1990@wotan.suse.de> <20160407185148.GL1990@wotan.suse.de> <5707BD2E.20204@citrix.com> <20160408215854.GU1990@wotan.suse.de> <20160413095428.5mcbrimvc6vxffcw@mac> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160413095428.5mcbrimvc6vxffcw@mac> 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 Content-Length: 1908 Lines: 40 On Wed, Apr 13, 2016 at 11:54:29AM +0200, Roger Pau Monn? wrote: > On Fri, Apr 08, 2016 at 11:58:54PM +0200, Luis R. Rodriguez wrote: > > 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? It seems there is a confusion on terms used. By folding legacy support under HVMLite I meant folding legacy PV path (classic PV with PV interfaces) under HVMlite. I got the impression that if we wanted to remove the old PV path we had to see if we can address old classic PV x86 guests through HVMlite, otherwise we'd have to live with the old PV path for the long term. > > * 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. Using the terms you use by "Leave legacy stuff on the old PV path" I meant not having to address classic PV guest support through HVMLite. Luis