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

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

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

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

I prefer 2.

Ian.

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