From mboxrd@z Thu Jan  1 00:00:00 1970
From: Roger Pau Monne <roger.pau@citrix.com>
Subject: [PATCH RFC v1 00/13] Introduce HMV without dm and new
	boot ABI
Date: Mon, 22 Jun 2015 18:11:14 +0200
Message-ID: <1434989487-74940-1-git-send-email-roger.pau@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=60808c7ad=roger.pau@citrix.com>)
	id 1Z74Ju-0007y6-1d
	for xen-devel@lists.xenproject.org; Mon, 22 Jun 2015 16:11:38 +0000
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: xen-devel@lists.xenproject.org
List-Id: xen-devel@lists.xenproject.org

Before reading any further, keep in mind this is a VERY inital RFC 
prototype series. Many things are not finished, and those that are done 
make heavy use of duck tape in order to keep things into place.

Now that you are warned, this series is split in the following order:

 - Patches from 1 to 7 switch HVM domain contruction to use the xc_dom_* 
   family of functions, like they are used to build PV domains. 
 - Patches from 8 to 13 introduce the creation of HVM domains without 
   firmware, which is replaced by directly loading a kernel like it's done 
   for PV guests. A new boot ABI based on the discussion in the thread "RFC: 
   making the PVH 64bit ABI as stable" is also introduced, although it's not 
   finished.

Some things that are missing from the new boot ABI:

 - Although it supports loading a ramdisk, there's still now defined way 
   into how to pass this ramdisk to the guest. I'm thinking of using a 
   HVMPARAM or simply setting a GP register to contain the address of the 
   ramdisk. Ideally I would like to support loading more than one ramdisk.

Some patches contain comments after the SoB, which in general describe the 
shortcommings of the implementation. The aim of those is to initiate 
discussion about whether the aproach taken is TRTTD.

I've only tested this on Intel hw, but I see no reason why it shouldn't work 
on AMD. I've managed to boot FreeBSD up to the point were it should 
jump into user-space (I just didn't have a VBD attached to the VM so it just 
sits waiting for a valid disk). I have not tried to boot it any further 
since I think that's fine for the purpose of this series. 

The series can also be found in the following git repo:

git://xenbits.xen.org/people/royger/xen.git branch hvm_without_dm_v1

And for the FreeBSD part:

git://xenbits.xen.org/people/royger/freebsd.git branch new_entry_point_v1

In case someone wants to give it a try, I've uploaded a FreeBSD kernel that 
should work when booted into this mode:

https://people.freebsd.org/~royger/kernel_no_dm

The config file that I've used is:

<config>
kernel="/path/to/kernel_no_dm"

builder="hvm"
device_model_version="none"

memory=128
vcpus=1
name = "freebsd"
</config>

Thanks, Roger.