Re: [libvirt] [PATCH v3 0/5] libxl: PVHv2 support

On 9/30/18 8:15 PM, Marek Marczykowski-Górecki wrote: > This is a respin of my old PVHv1 patch[1], converted to PVHv2. > Should the code use "PVH" name (as libxl does internally), or "PVHv2" as in > many places in Xen documentation? I've chosen the former, but want to confirm > it. "PVH". > > Also, not sure about VIR_DOMAIN_OSTYPE_XENPVH (as discussed on PVHv1 patch) - > while it will be messy in many cases, there is > libxl_domain_build_info.u.{hvm,pv,pvh} which would be good to not mess up. > Also, PVHv2 needs different kernel features than PV (CONFIG_XEN_PVH vs > CONFIG_XEN_PV), so keeping the same VIR_DOMAIN_OSTYPE_XEN could be > confusing. These are good reasons for going with VIR_DOMAIN_OSTYPE_XENPVH. Another is it avoids the STREQ(def->os.machine, "xenpvh"), which I think others will find appealing. > On the other hand, libxl_domain_build_info.u.pv is used in very few places (one > section of libxlMakeDomBuildInfo), so guarding u.hvm access with > VIR_DOMAIN_OSTYPE_HVM may be enough. > For now I've reused VIR_DOMAIN_OSTYPE_XEN - in the driver itself, most of > the code is the same as for PV. I'll reiterate my rationalization for using VIR_DOMAIN_OSTYPE_XEN for both and differentiating them with os.machine: both PV and PVH are OS types that have been modified to run on Xen. I'd still like to get some opinions from other maintainers on this. Anyone care to share their thoughts on which approach best models PVH?