From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI Date: Fri, 3 Jul 2015 17:22:45 +0100 Message-ID: <20150703162245.GB86947@deinos.phlegethon.org> References: <1434989487-74940-1-git-send-email-roger.pau@citrix.com> <20150622180544.GA9175@l.oracle.com> <558A7CC5.7060400@citrix.com> <558A9CEC0200007800088C28@mail.emea.novell.com> <558A831F.8020407@citrix.com> <558A9A15.6050807@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB3jx-00073S-FT for xen-devel@lists.xenproject.org; Fri, 03 Jul 2015 16:23:02 +0000 Content-Disposition: inline In-Reply-To: <558A9A15.6050807@oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Boris Ostrovsky Cc: elena.ufimtseva@oracle.com, wei.liu2@citrix.com, Ian Campbell , Stefano Stabellini , andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com, Jan Beulich , xen-devel@lists.xenproject.org, Roger Pau =?iso-8859-1?Q?Monn=E9?= List-Id: xen-devel@lists.xenproject.org At 07:52 -0400 on 24 Jun (1435132373), Boris Ostrovsky wrote: > On 06/24/2015 06:14 AM, Roger Pau Monn=E9 wrote: > > El 24/06/15 a les 12.05, Jan Beulich ha escrit: > >>>>> On 24.06.15 at 11:47, wrote: > >>> What needs to be done (ordered by priority): > >>> > >>> - Clean up the patches, this patch series was done in less than a w= eek. > >>> - Finish the boot ABI (this would also be needed for PVH anyway). > >>> - Convert the rest of xc_dom_*loaders in order to use the physical > >>> entry point when present, right now xc_dom_elfloader is the only = one > >>> usable with HVMlite. This is quite trivial (see patch 10, it's a 4 > >>> LOC change). > >>> - Dom0 support. > >>> - Migration. > >>> - PCI pass-through. > >>> > >>> IMHO this is what we agreed to do with PVH, make it an HVM guest with= out > >>> a device model and without the emulated devices inside of Xen. Sooner= or > >>> later we would need to make that change anyway in order to properly > >>> integrate PVH into Xen, and we get a bunch of new features for free as > >>> compared to PVH. > >>> > >>> I don't think of this as "throw PVH out of the window and start > >>> something completely new from scratch", we are going to reuse some of > >>> the code paths used by PVH inside of Xen. From a guest POV the changes > >>> needed to move from PVH into HVMlite are regarding the boot ABI only, > >>> which we already agreed that should be changed anyway. > >> I have to admit that I'm having a hard time making myself a clear > >> picture of what the intention now is, namely with feature freeze > >> being in about 2.5 weeks: If we assume that this series gets ready > >> in time, should we drop Boris' 32-bit support patches? Would then > >> be unfortunate if the series here didn't get ready. > > TBH I'm not going to make any promises of this being ready before the > > 4.6 feature freeze, not until I get some feedback from the tools > > maintainers regarding the libxc changes to unify the PV and HVM domain > > creation paths. > = > FWIW, I gave this a quick spin on Monday and crashed the hypervisor on a = > NULL pointer right away in vapic code. Which, I assume, is not = > surprising since we are not supposed to be there in the first place. > = > I'll try it again later today (I was out yesterday), maybe I messed = > something up. > = > > > >> Otoh I don't think this and Boris' code conflict, and what we got in > >> the tree PVH-wise is kind of a mess right now anyway, so adding to > >> it just a few more bits (actually getting rid of some fixme-s, i.e. > >> reducing messiness), so I'd be inclined to take the rest of Boris' > >> series once ready, and if the series here gets ready too it could > >> then also go in. Which would then mean for someone (perhaps > >> after 4.6 was branched) to clean up any no longer necessary > >> PVH special cases, unifying things towards what we seem to now > >> call HVMlite. > > I'm not against merging the 32bit support series for PVH, but I'm > > certainly not going to invest time in adding 32bit PVH entry points to > > any OSes. > = > What about Tim's proposal = > (http://lists.xen.org/archives/html/xen-devel/2014-12/msg00596.html)? = > Can this work be made part of it? At least, make it extendable to that? FWIW, I think this new scheme (start at HVM and remove things) is approaching the same end result from the other direction: Xen itself no longer needs to have a concept of PVH, and the guests get to keep their useful new interface. As such, I heartily approve. :) Cheers, Tim.