From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?windows-1252?Q?Roger_Pau_Monn=E9?= Subject: Re: [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI Date: Wed, 24 Jun 2015 12:14:55 +0200 Message-ID: <558A831F.8020407@citrix.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z7hhs-0002ZF-TN for xen-devel@lists.xenproject.org; Wed, 24 Jun 2015 10:15:01 +0000 In-Reply-To: <558A9CEC0200007800088C28@mail.emea.novell.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: 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, boris.ostrovsky@oracle.com List-Id: xen-devel@lists.xenproject.org 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 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. > 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. Roger.