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

On 10/2/18 3:38 PM, Jim Fehlig wrote: > 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? I've been thinking about this more and AFAIK on the qemu side the machine attribute models a chipset, e.g. <type arch='x86_64' machine='pc-i440fx'>hvm</type> <type arch='x86_64' machine='pc-q35'>hvm</type> Is it a stretch to refer to PV and PVH as chipsets? If so, my position on the fence in now leaning towards VIR_DOMAIN_OSTYPE_XENPVH :-/