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

[Tim Deegan <tim@xxxxxxx>]

At 07:52 -0400 on 24 Jun (1435132373), Boris Ostrovsky wrote:
> 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@xxxxxxxxxx> 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?

FWIW, I think this new scheme (start at HVM and remove things) is
approaching the same end result from the other direction: Xen itself
no longer needs to have a concept of PVH, and the guests get to keep
their useful new interface.  As such, I heartily approve. :)

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel