Re: [Xen-devel] [PATCH 04/19] libxl: introduce a PVH guest type

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

On Thu, Aug 24, 2017 at 12:42:29PM +0100, Wei Liu wrote:
> On Tue, Aug 22, 2017 at 10:49:05AM +0100, Roger Pau Monne wrote:
> > The new guest type is introduced to the libxl IDL. libxl__domain_make
> > is also modified to save the guest type, and libxl__domain_type is
> > expanded to fetch that information when detecting guest type.
> > 
> > This is required because the hypervisor only differentiates between PV
> > and HVM guests, so libxl needs some extra information in order to
> > differentiate between a HVM and a PVH guest.
> > 
> > The new PVH guest type and it's options are documented on the xl.cfg
> 
> it's -> its
> 
> >  
> >  =back
> >  
> > +=head2 PVH Guest Specific Options
> > +
> > +=over 4
> > +
> > +=item B<nestedhvm=BOOLEAN>
> > +
> > +Enable or disables guest access to hardware virtualisation features,
> > +e.g. it allows a guest Operating System to also function as a
> > +hypervisor. You may want this
> > +option if you want to run another hypervisor (including another copy
> > +of Xen) within a Xen guest or to support a guest Operating System
> > +which uses hardware virtualisation extensions (e.g. Windows XP
> > +compatibility mode on more modern Windows OS).
> > +This option is disabled by default.
> 
> Line wrapping is a bit strange.

That's a verbatim copy of the original text, I should have reformatted
it.

> >  
> >  libxl_rdm_reserve_strategy = Enumeration("rdm_reserve_strategy", [
> > @@ -589,6 +590,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
> >                                        # Use host's E820 for PCI 
> > passthrough.
> >                                        ("e820_host", libxl_defbool),
> >                                        ])),
> > +                 ("pvh", None),
> 
> So PVH type doesn't have its fields?

No, patch 1 moves the fields relevant for PVH to the top-level
structure.

> I was thinking the resolution was to provide a type (an interface) with
> its own fields (albeit identical to hvm fields), but I could be wrong.

I think Ian didn't want to introduce a new PVH sub-struct, but I could
be wrong. Introducing a new sub-struct would also make the code
slightly more complex, since libxl would have to check for
pv.bootloader and pvh.bootloader, or hvm.nested_hvm and pvh.nested_hvm
depending on guest type.

I guess we should defer the decision on the position of the fields
until Ian comes back.

Thanks, Roger.

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