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

From: Ian Jackson <ian.jackson@eu.citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Elena Ufimtseva <elena.ufimtseva@oracle.com>,
	Kevin Tian <kevin.tian@intel.com>,
	Tamas K Lengyel <tamas@tklengyel.com>,
	Wei Liu <wei.liu2@citrix.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Razvan Cojocaru <rcojocaru@bitdefender.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Paul Durrant <paul.durrant@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 1/3] x86: remove PVHv1 code
Date: Wed, 1 Mar 2017 15:30:13 +0000	[thread overview]
Message-ID: <22710.59653.663181.663658@mariner.uk.xensource.com> (raw)
In-Reply-To: <20170301152401.vsdfydprrmm5l66e@dhcp-3-221.uk.xensource.com>

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@lists.xen.org
https://lists.xen.org/xen-devel