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

From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>,
	"Jan Beulich" <JBeulich@suse.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
Subject: Re: [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI
Date: Wed, 24 Jun 2015 07:52:53 -0400	[thread overview]
Message-ID: <558A9A15.6050807@oracle.com> (raw)
In-Reply-To: <558A831F.8020407@citrix.com>

On 06/24/2015 06:14 AM, Roger Pau Monné wrote:
> El 24/06/15 a les 12.05, Jan Beulich ha escrit:
>>>>> 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.
> 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