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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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.

> 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.


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