From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI Date: Wed, 24 Jun 2015 07:52:53 -0400 Message-ID: <558A9A15.6050807@oracle.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" 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 1Z7jEp-0002w1-JO for xen-devel@lists.xenproject.org; Wed, 24 Jun 2015 11:53:07 +0000 In-Reply-To: <558A831F.8020407@citrix.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: =?windows-1252?Q?Roger_Pau_Monn=E9?= , Jan Beulich Cc: elena.ufimtseva@oracle.com, wei.liu2@citrix.com, Ian Campbell , Stefano Stabellini , andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org 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 wee= k. >>> - 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 without >>> 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? -boris