From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI Date: Wed, 24 Jun 2015 09:36:57 -0400 Message-ID: <20150624133657.GC9618@l.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> <558A9A15.6050807@oracle.com> <558A9CDD.5090108@citrix.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 1Z7krU-0003wx-Se for xen-devel@lists.xenproject.org; Wed, 24 Jun 2015 13:37:09 +0000 Content-Disposition: inline In-Reply-To: <558A9CDD.5090108@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: Roger Pau =?iso-8859-1?Q?Monn=E9?= 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, Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org On Wed, Jun 24, 2015 at 02:04:45PM +0200, Roger Pau Monn=E9 wrote: > El 24/06/15 a les 13.52, Boris Ostrovsky ha escrit: > > 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 > >>>> week. > >>>> - 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 chang= es > >>>> 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. > = > Yes, feature disabling is still not 100% done I'm afraid. For example if > your hw supports vAPIC it will be enabled anyway, which can then lead to > all kinds of trouble. As said, this is very initial and I've only tested > it on one Nehalem box which doesn't have vAPIC. > = > >> > >>> 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? > = > Yes, the aim of this work is to address some of the points expressed in > that email, mainly merge PVH into HVM. But as we have already spoken, > the entry point of HVMlite or whatever we call it is going to be > different from the traditional PV/PVH entry point. Right. If you were to take a sharpie where would you put in the = list that Tim had written out? And to my eye - it looks as the HVMLIte boot entry and the old PVH bootpaths can co-exist for some time until they get merged together? This would have the nice benefit of being able to troubleshoot issues easier as you have an existing codepath for 'old-PVH' = and new bootup path and can figure out what is missing to make it work (with the Linux kernel at least).