From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v4 31/31] libxl: allow the creation of HVM
 domains without a device model.
Date: Fri, 7 Aug 2015 18:52:45 +0100
Message-ID: <55C4F06D.4040003@citrix.com>
References: <1438942688-7610-1-git-send-email-roger.pau@citrix.com>
	<1438942688-7610-32-git-send-email-roger.pau@citrix.com>
	<20150807151844.GO29527@l.oracle.com> <55C4D551.4060402@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=654663106=Andrew.Cooper3@citrix.com>)
	id 1ZNlpG-0001aA-Ou
	for xen-devel@lists.xenproject.org; Fri, 07 Aug 2015 17:53:02 +0000
In-Reply-To: <55C4D551.4060402@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: =?windows-1252?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>, Konrad
	Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xenproject.org, Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

On 07/08/15 16:57, Roger Pau Monn=E9 wrote:
> El 07/08/15 a les 17.18, Konrad Rzeszutek Wilk ha escrit:
>> On Fri, Aug 07, 2015 at 12:18:08PM +0200, Roger Pau Monne wrote:
>>> Replace the firmware loaded into HVM guests with an OS kernel. Since th=
e HVM
>>> builder now uses the PV xc_dom_* set of functions this kernel will be p=
arsed
>>> and loaded inside the guest like on PV, but the container is a pure HVM
>>> guest.
>> What is your plan in regards to the 'pvh' parameteR? Should it be
>> repurposed so you can use both?
> I haven't thought about this TBH.
>
> One option could be to make the pvh parameter an alias to builder=3D'hvm'
> device_model_version=3D'none' with a forced 64bit entry point, but since
> PVH has never made it out of the experimental state I'm not sure if it's
> worth to keep it.

We can't remove it from the libxl API as it has been released now, even
if the underlying feature was only ever experimental.

As we plan to do some retroactive renaming at some point, it is probably
fine to keep "pvh=3D1" as a shorthand for "set me up the required bits
please".

~Andrew