[libvirt] [PATCH v4 2/5] libxl: add support for PVH

[Jim Fehlig]

On 10/16/18 7:23 PM, Marek Marczykowski-Górecki wrote:
> On Sat, Oct 13, 2018 at 08:46:19AM -0600, Jim Fehlig wrote:
>> I had some couch time at the start of the weekend and was finally able to
>> try using this series with virt-install. As it turns out, reporting
>> duplicate <guest> blocks for <os_type> 'xen' is not quite right. Instead we
>> will want to report the additional <machine> under the existing 'xen'
>> <guest> blocks. E.g. instead of adding a duplicate
>>
>>    <guest>
>>      <os_type>xen</os_type>
>>      <arch name='x86_64'>
>>        <wordsize>64</wordsize>
>>        <emulator>/usr/lib/xen/bin/qemu-system-i386</emulator>
>>        <machine>xenpvh</machine>
>>        <domain type='xen'/>
>>      </arch>
>>      ...
>>    </guest>
>>
>> we'll want to include the xenpvh machine in the existing <guest> config for xen
>>
>>    <guest>
>>      <os_type>xen</os_type>
>>      <arch name='x86_64'>
>>        <wordsize>64</wordsize>
>>        <emulator>/usr/lib/xen/bin/qemu-system-i386</emulator>
>>        <machine>xenpvh</machine>
>>        <machine>xenpv</machine>
>>        <domain type='xen'/>
>>      </arch>
>>    </guest>
>>
>> With this change to the capabilities reporting, virt-install works without
>> modification using
>>
>> virt-install --paravirt --machine xenpv ...
>>
>> I didn't think too hard about the best way to handle this, but the attached
>> diff is a POC hack that works with unmodified virt-install.
> 
> I can get it reported this way, but it will be wrong, because <features>
> will be incorrectly reported. For example hap should be reported for
> xenpvh, but not for xenpv, so bundling them together makes it
> impossible. Similar for acpi and probably others too.

Yes, you are correct :-(. Modeling PVH has been more of a PITA than I expected.

> 
> If this really needs to be reported together, I'd go with reporting
> superset of features, so os_type xen entry will have all features of PV
> and PVH.

Reporting features that cannot possibly be supported doesn't see right. Let's 
summarize what we've learned thus far and see if that helps with modeling PVH.

PVH is a new xen machine type that is a hybrid of PV and HVM. Like HVM, PVH 
requires hardware virtualization support. Like PV, PVH requires a modified guest 
kernel, and one that is modified differently than PV (e.g. CONFIG_XEN_PVH vs
CONFIG_XEN_PV in the linux kernel). PV and PVH have different feature sets. E.g. 
PVH supports HAP, ACPI, etc., but PV does not. (Perhaps another useful data 
point: the long term goal of the xen community is to remove CONFIG_XEN_PV, 
essentially making PVH the new PV from xen perspective, but that is obviously a 
long ways out.)

Currently in libvirt, PV is modeled as VIR_DOMAIN_OSTYPE_XEN and machine 
"xenpv". HVM is modeled as VIR_DOMAIN_OSTYPE_HVM and machine "xenfv". For PVH 
we've considered VIR_DOMAIN_OSTYPE_XENPVH with machine "xenpvh", or simply 
adding PVH as machine "xenpvh" under existing VIR_DOMAIN_OSTYPE_XEN.

I've pushed for adding a new machine "xenpvh" under existing 
VIR_DOMAIN_OSTYPE_XEN with primary reason that both are OS types modified to run 
on xen. Also existing tools like virt-{install,manager} know how to handle 
OSTYPE_{HVM,XEN} and machines, allowing them to support PVH without (or with 
minimal) modification.

Have I been narrow-minded with my "both are OS types modified to run on xen" 
reasoning for using VIR_DOMAIN_OSTYPE_XEN? Should we really consider PVH a new 
OSTYPE? Your reminder that PV and PVH have a different feature set hints to 
modeling PVH as VIR_DOMAIN_OSTYPE_XENPVH. It is unfortunate that tools above 
libvirt would have to be taught about this new OSTYPE, but that shouldn't 
prevent using VIR_DOMAIN_OSTYPE_XENPVH if in fact it is the best way to model PVH.

Sadly I haven't strongly convinced myself one way or the other. I still like the 
idea of reusing VIR_DOMAIN_OSTYPE_XEN and adding machine "xenpvh" since it seems 
easier from an app perspective, but maybe I just need slapped and admit that PVH 
is a new OSTYPE. (I'm sure you'd like to do the slapping at this point...)

Regards,
Jim