[Xen-devel] Introduce PVH domU support

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

This patch series is a reworking of a series developed by Mukesh
Rathor at Oracle.  The entirety of the design and development was done
by him; I have only reworked, reorganized, and simplified things in a
way that I think makes more sense.  The vast majority of the credit
for this effort therefore goes to him.  This version is labelled v12
because it is based on his most recent series, v11.

Because this is based on his work, I retain the "Signed-off-by" in
patches which are based on his code.  This is not meant to imply that
he supports the modified version, only that he is involved in
certifying that the origin of the code for copyright purposes.

This is still an RFC, and in several places I have kept code as I
found it even though I didn't understand it or didn't agree with it
because I wanted to be able to discuss it.

This patch series is broken down into several broad strokes:
* Miscellaneous fixes or tweaks
* Code motion, so future patches are simpler
* Introduction of the "hvm_container" concept, which will form the
basis for sharing codepaths between hvm and pvh
* Start with HVM as an HVM container
* Disable unneeded HVM functionality
* Enable PV functionality
* Disable not-yet-implemented functionality

This patch series can also be pulled from this git tree:
 git://xenbits.xen.org/people/gdunlap/xen.git out/pvh-v12

This series is does *not* have the toolstack side patches; those
patches must be applied, and in addition, must be modified to add
XEN_DOMCTL_CDF_pvh_guest in addition to _hap for PVH guests.  (I'll
probably include those in this series at some point, but I wanted to
get a first draft out there.)

The kernel code for PVH guests can be found here:
 git://oss.oracle.com/git/mrathor/linux.git pvh.v9-muk-1
(That repo/branch also contains a config file, pvh-config-file)

For those who have been following the series as it develops, here is a
summary of the major changes from Mukesh's series:

* Introduction of "has_hvm_container_*()" macros, rather than using
  "!is_pv_*".  The patch which introduces this also does the vast
  majority of the "heavy lifting" in terms of defining PVH.

* Effort is made to use as much common code as possible.  No separate
  vmcs constructor, no separate vmexit handlers.  More of a "start
  with everything and disable if necessary" approach rather than
  "start with nothing and enable as needed" approach.

* One exception is arch_set_info_guest(), where a small amount of code
  duplication meant a lot fewer "if(!is_pvh_domain())"s in awkward
  places

* I rely on things being disabled at a higher level and passed down.
  For instance, I no longer explicitly disable rdtsc exiting in
  construct_vmcs(), since that will happen automatically when we're in
  NEVER_EMULATE mode (which is currently enforced for PVH).  Similarly
  for nested vmx and things relating to HAP mode.

* I have also done a slightly more extensive audit of is_pv_* and
  is_hvm_* and tried to do more restrictions.

* I changed the "enable PVH by setting PV + HAP", replacing it instead
  with a separate flag, just like the HVM case, since it makes sense
  to plan on using shadow in the future (although it is 

Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
CC: Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
CC: Jan Beulich <jan.beulich@xxxxxxxx>
CC: Tim Deegan <tim@xxxxxxx>
CC: Keir Fraser <keir@xxxxxxx>


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