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

[Jim Fehlig]

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 :-/

Regards,
Jim