[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [PATCH RFC v13 00/20] Introduce PVH domU support



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 v13
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 PVH as an HVM container
* Disable unneeded HVM functionality
* Enable PV functionality
* Disable not-yet-implemented functionality
* Enable toolstack changes required to make PVH guests

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

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)

Changes in v13 can be found inline; major changes since v12 include:

* Include Mukesh's toolstack patches (v4)

* Allocate hvm_param struct for PVH domains; remove patch disabling
  memevents

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

* 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 <beulich@xxxxxxxx>
CC: Tim Deegan <tim@xxxxxxx>
CC: Keir Fraser <keir@xxxxxxx>
CC: Ian Jackson <ian.jackson@xxxxxxxxxx>
CC: Ian Campbell <ian.campbell@xxxxxxxxxx>


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.