[Xen-devel] [PATCH v3 00/22] libxl/xl: add PVH guest type

[Roger Pau Monne <roger.pau@xxxxxxxxxx>]

Hello,

This series adds a new PVH guest type to libxl/xl, this supersedes the
current PVHv2 implementation that relies on using the "none" device
model version.

As part of this series a new xl option is also implemented, called
"type" that supersedes the current "builder" option. A "firmware"
option is also introduced in order to have a uniform way of loading
firmwares for all guest types (HVM, PV and PVH).

Patch 1 adds a default value checker for the string and timer_mode
types, and patch 2 introduces IDL code to generate a helper function
that copies fields marked as deprecated to their new positions. I'm
not specially fond of this deprecation function, but given my lack of
python skills, the closeness of the code freeze I think it's enough
for the purposes of this series.

This is already used to move some PV/HVM specific fields from
domain_build_info into the top level of the structure. Finally patch 4
switches libxl to use the new field position.

Patches 5 and 6 introduce the new type
and firmware options. Patch 7 introduces the PVH guest type to libxl.

Patches from 8 to 20 add PVH support to all the needed functions, this
could be considered a single patch, but I've tried to split it in
order to ease the review. The current split is done on a per file
basis.

Finally patch 21 adds PVH support to xl and patch 22 removes the
device model version "none".

This implementation is based on the discussion held during the
Budapest XenSummit [0].

The full series can be found at:

git://xenbits.xen.org/people/royger/xen.git pvh_tools_v3

I've tested the creation and migration of PVH guests, which seems to
be all OK. I've also run an osstest flight with this series, the
output can be seen at:

http://osstest.xs.citrite.net/~osstest/testlogs/logs/72144/

(Only accessible from the Citrix internal network, sorry)

The regressions seen on some of the Windows tests are caused by trying
to create a VM with a memory size bigger than the available memory
(check domain.cfg and xl info output), and the test-amd64-amd64-pygrub
failed the leak-check step because it found an unexpected exim4
process. I don't think any of those failures are caused by this
series.

Thanks, Roger.


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