[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |