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

Re: [Xen-devel] [PATCH v2 1/3] x86: remove PVHv1 code



Roger Pau Monne writes ("Re: [PATCH v2 1/3] x86: remove PVHv1 code"):
> On Tue, Feb 28, 2017 at 05:44:51PM +0000, Ian Jackson wrote:
> > Are those explicit settings even a supported way to create a PVHv2
> > domain ?  I think they probably shouldn't be.
> 
> Those are the only ways to create a PVHv2 domain ATM (without this
> patch, obviously). I don't mind making pvh the canonical way to
> create a PVHv2 guest.

Well, PVHv2 is in the process of becoming properly supported, so now
is the time to decide the "official" way.

> > > +        c_info->type = LIBXL_DOMAIN_TYPE_HVM;
> > > +        b_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_NONE;
...
> > I think this should probably be done in libxl, not xl.
> 
> That was my first attempt, but it's not trivial. PVHv1 assumes that
> the domain type is PV, so it will basically fill the PV side of the
> libxl_domain_build_info union, and that's bad. Because options like
> "hap" or "nestedhvm" are not even considered valid for PV guests,
> and there's no way for libxl to re-parse the configuration, so
> AFAICT the only proper way to solve this is to set the domain type
> correctly as soon as the "pvh" option is detected.

When you say "it will basically fill the PV side", what is "it" ?
Do you mean xl_parse.c ?

Isn't this what libxl_domain_build_info_init_type is for ?

Ian.

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

 


Rackspace

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