Re: [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI

From: "Jan Beulich" <JBeulich@suse.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: elena.ufimtseva@oracle.com, wei.liu2@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com
Subject: Re: [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI
Date: Wed, 24 Jun 2015 11:05:00 +0100	[thread overview]
Message-ID: <558A9CEC0200007800088C28@mail.emea.novell.com> (raw)
In-Reply-To: <558A7CC5.7060400@citrix.com>

>>> On 24.06.15 at 11:47, <roger.pau@citrix.com> 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.

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.

Jan