Re: [Xen-devel] [PATCH v2 1/3] x86: remove PVHv1 code

[Roger Pau Monne <roger.pau@xxxxxxxxxx>]

On Wed, Mar 01, 2017 at 02:51:33PM +0000, Ian Jackson wrote:
> Roger Pau Monne writes ("Re: [PATCH v2 1/3] x86: remove PVHv1 code"):
> > It's not just the CPU extensions, we are also providing it with a
> > local APIC and ACPI tables,
> 
> The host and guest system administrators do not care about any of
> that.  These are implementation details.
> 
> > and it looks like we will also have OVMF
> > firmware support for PVH in the near future.
> 
> That just means it boots more like HVM.  But we have gradually been
> moving towards more "normal" kind of booting for a long time.  For
> example, AIUI ARM guests always boot with the same kind of firmware.
> 
> The need for weird booting arrangements has always been a difficulty
> with PV which it is nice to get rid of.
> 
> > This is all just a question of taste at the end, but to me it tastes
> > much more like HVM rather than PV.
> 
> I can see that it very much looks this way from the point of view of
> the implementors on both sides of the guest ABI.  So yes, it "tastes
> much more like HVM" from the point of view of a guest kernel
> programmer, or a Xen hypervisor programmer.
> 
> But config files are supposed to be written by nonprogrammers (or by
> toolstack or orchestration system programmers).

OK, I can be convinced that this is better.

It still feels strange to me to market this as a new guest type, when it's just
a HVM guest in disguise (or maybe I should say nude due to the lack of
QEMU?).

> > > So I think having libxl_domain_build_info_init_type set type to HVM if
> > > pvh=1 would solve the problem.
> > 
> > I've looked at it again, and no, libxl_domain_build_info_init_type
> > when called from parse_config_data is not able to set the type of
> > the guest to HVM. This is it's prototype:
> > 
> > libxl_domain_build_info_init_type(libxl_domain_build_info *p, 
> > libxl_domain_type type);
> > 
> > Type (second parameter) is PV when pvh=1 is set, and that's all the
> > info provided. libxl_domain_build_info_init_type has no way to know
> > whether the info it's initializing is for a PV or PVH guest, because
> > it's lacking context.
> 
> Well, then I think we should do one of two things:
> 
>  1. Make a new libxl_domain_build_info_init_type (with compatibility
>     arrangements) which takes &c_info, not just &c_info.type.
> 
>  2. Extend the domain type enum, ie invent LIBXL_DOMAIN_TYPE_PVH.
>     Its struct would be the same as for hvm.

Hm, I think I prefer 1. because it means I won't have to add duplicate
LIBXL_DOMAIN_TYPE_PVH cases/conditions together with every
existing LIBXL_DOMAIN_TYPE_HVM one.

Roger.

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