Re: [Xen-devel] [PATCH 00/19] libxl/xl: add PVH guest type

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

On Tue, Aug 22, 2017 at 01:33:55PM +0100, Andrew Cooper wrote:
> On 22/08/17 12:30, Roger Pau Monne wrote:
> > On Tue, Aug 22, 2017 at 12:24:29PM +0100, Andrew Cooper wrote:
> >> On 22/08/17 10:49, Roger Pau Monne wrote:
> >>> 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 lifts some fields from the libxl_domain_build_info domain
> >>> specific sub-structs into libxl_domain_build_info itself, so they can
> >>> be used by all domain types. Patches 2 and 3 introduce the new type
> >>> and firmware options. Patch 4 introduces the PVH guest type to libxl.
> >>>
> >>> Patches from 5 to 17 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 18 adds PVH support to xl and patch 19 removes the
> >>> device model version "none".
> >> Can we keep none as an option, even if it looses its special PVH
> >> meaning?  I've got some plans for XTF testing where part of the test
> >> plays the part of qemu by connecting to the ioreq server, and having an
> >> ability to configure "no device model - I know what I'm doing" would be
> >> necessary.
> > I guess you cannot do that with PVH because you want the full set of
> > emulated devices by Xen to be available to XTF?
> 
> Whether a device model exists is logically independent of the type of guest.
> 
> It is important to be able to test all combinations.

I'm not opposed to leaving device model version "none", but sadly this
option has been abused, so IIRC device model version "none" implies
that you won't get QEMU for the PV disk backends.

Does what you plan to do work if the last patch is dropped? I bet it
needs much more massaging due to the amounts of switches based on the
device model version.

Maybe you need a device_model_override_path instead, or something
similar?

Roger.

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