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"):
> On Wed, Mar 01, 2017 at 02:51:33PM +0000, Ian Jackson wrote:
> > 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.

Thanks.

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

Indeed it is just an HVM guest in disguise.  But libxl ought to
help maintain that "disguise", not expose the underlying "truth".

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

You're thinking from an implementation point of view again.  Adding
those additional cases inside libxl is striaghtforward, if a bit
tedious.

We should be looking at this from the point of view of the application
(toolstack) programmer who is calling libxl.

We are advertising three guest types now: PV, HVM, PVH.  ISTM that the
new guest type should be a guest type.

Ian.

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