From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753814AbcDMUBX (ORCPT ); Wed, 13 Apr 2016 16:01:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:40586 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753546AbcDMUBU (ORCPT ); Wed, 13 Apr 2016 16:01:20 -0400 Date: Wed, 13 Apr 2016 22:01:18 +0200 From: "Luis R. Rodriguez" To: Konrad Rzeszutek Wilk Cc: "Luis R. Rodriguez" , Roger Pau =?iso-8859-1?Q?Monn=E9?= , Matt Fleming , jeffm@suse.com, Michael Chang , Linux Kernel Mailing List , Jim Fehlig , Jan Beulich , "H. Peter Anvin" , Daniel Kiper , the arch/x86 maintainers , Takashi Iwai , =?utf-8?Q?Vojt=C4=9Bch_Pavl=C3=ADk?= , Gary Lin , xen-devel , Jeffrey Cheung , Juergen Gross , Stefano Stabellini , Julien Grall , George Dunlap , joeyli , Borislav Petkov , Boris Ostrovsky , Charles Arndol , Andrew Cooper , Julien Grall , Andy Lutomirski , David Vrabel , torvalds@linux-foundation.org Subject: Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry Message-ID: <20160413200118.GC1990@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> <20160413185010.GX1990@wotan.suse.de> <20160413190226.GB7501@char.us.oracle.com> <20160413191408.GA1990@wotan.suse.de> <20160413192223.GA19026@char.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160413192223.GA19026@char.us.oracle.com> 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 Wed, Apr 13, 2016 at 03:22:23PM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Apr 13, 2016 at 09:14:08PM +0200, Luis R. Rodriguez wrote: > > On Wed, Apr 13, 2016 at 03:02:26PM -0400, Konrad Rzeszutek Wilk wrote: > > > On Wed, Apr 13, 2016 at 08:50:10PM +0200, Luis R. Rodriguez wrote: > > > > 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. > > > > > > Ewww. > > > > Probably a confusion again on terms, by the above I meant to say what you seem > > to be indicating below, which is to keep old PV guest support with PV interfaces > > using a new shiny entry. > > > > Or are we really going to nuke full support for old PV guests ? > > Please re-read my email. The hypervisor is not going to nuke it. Linux > will stop using them - and hence the pvops will be obsolete. I meant remove old PV guests support from Linux. You made it crystal clear that the hypervisor will keep legacy PV support. Are we going to remove old PV guest support from Linux upstream long term ? If so then HVMLite design need not be concerned with supporting legacy crap. > > > > 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. > > > > > > No. We need to deprecate the PV paths - and the agreement we hammered out > > > with the x86 maintainers was that once PVH/HVMLite is stable the clock > > > would start ticking on PV (pvops) life. All the big users of PV Linux > > > were told in persons to prep them for this. > > > > That's nice. *How* that is done is what we are determining here. > > What is being discussed is how PVH/HVMLite is suppose to bootup. > Or the merits of different bootup paths. That's part of it... > Unless you are saying that you want to be the maintainer of pvops > and want to extend the life of pvops in Linux and are trying to make > it work under HVMLite? Huh? If you look at pvops commits you'll see I've been responsible for most of the pvops removal already, my ongoing patches should show that my goal is to streamline this further. I want to clarify now then what our exist path is, do we need to care about legacy crap ? Luis