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

Fri Oct 19 15:12:55 UTC 2018

On 10/19/18 8:59 AM, Daniel P. Berrangé wrote:
> On Fri, Oct 19, 2018 at 08:53:15AM -0600, Jim Fehlig wrote:
>> On 10/19/18 8:14 AM, Daniel P. Berrangé wrote:
>>> On Fri, Oct 19, 2018 at 08:06:18AM -0600, Jim Fehlig wrote:
>>>> On 10/19/18 3:11 AM, Daniel P. Berrangé wrote:
>>>>> On Thu, Oct 18, 2018 at 11:08:34AM -0600, Jim Fehlig wrote:
>>>>>> On 10/17/18 12:59 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.
>>>>>>>
>>>>>>> Is that virt-install limitation? In that case, IMO virt-install should
>>>>>>> be fixed, instead of changing capabilities xml to match its limitations.
>>>>>>
>>>>>> Perhaps it is a virt-install limitation, but my suggestion was based more on
>>>>>> how the qemu driver reports the different machines
>>>>>>
>>>>>> <guest>
>>>>>>      <os_type>hvm</os_type>
>>>>>>      <arch name='x86_64'>
>>>>>>        <wordsize>64</wordsize>
>>>>>>        <emulator>/usr/bin/qemu-system-x86_64</emulator>
>>>>>>        <machine maxCpus='255'>pc-i440fx-3.0</machine>
>>>>>>        <machine maxCpus='288'>pc-q35-3.0</machine>
>>>>>>        ...
>>>>>>      </arch>
>>>>>> </guest>
>>>>>>
>>>>>> Compare that with reporting PV and PVH in different <guest> blocks, where
>>>>>> the <os_type> and <arch> are the same. It seems confusing from a consumers
>>>>>> POV
>>>>>>
>>>>>> <guest>
>>>>>>      <os_type>xen</os_type>
>>>>>>      <arch name='x86_64'>
>>>>>>        <wordsize>64</wordsize>
>>>>>>        <emulator>/usr/bin/qemu-system-x86_64</emulator>
>>>>>>        <machine>xenpv</machine>
>>>>>>      </arch>
>>>>>> </guest>
>>>>>>
>>>>>> <guest>
>>>>>>      <os_type>xen</os_type>
>>>>>>      <arch name='x86_64'>
>>>>>>        <wordsize>64</wordsize>
>>>>>>        <emulator>/usr/bin/qemu-system-x86_64</emulator>
>>>>>>        <machine>xenpvh</machine>
>>>>>>      </arch>
>>>>>> </guest>
>>>>>>
>>>>>> How should a consumer interpret that? Is the machine for os_type=xen,
>>>>>> arch=x86_64 a xenpv or a xenpvh?
>>>>>
>>>>> Yes, you are right - any pair of (os_type, arch) should be unique
>>>>> in the capabilities XML. So all machines should be reported in the
>>>>> same block.
>>>>
>>>> Our difficulty with that is xenpv and xenpvh machines have different
>>>> features. Marek pointed out that the qemu driver reports the "feature"
>>>> maxCpus as an attribute on the machine element, but we're hesitant to keep
>>>> adding attributes for each feature that is unique to a machine.
>>>>
>>>> Another option we discussed was reporting a superset of all features so that
>>>> e.g. (xen, x86_64) block would contain features supported by both PV and PVH
>>>> and then rejecting unsupported features when parsing domXML or starting the
>>>> VM. This option is rather distasteful.
>>>>
>>>> And we also have the option of adding VIR_DOMAIN_OSTYPE_XENPVH, which I've
>>>> shied away from but may be a better way to go in the end. Do you have any
>>>> suggestions we may have overlooked?
>>>
>>> Oooh, it looks like i've been mis-understanding PVH in all my previous
>>> reviews.
>>>
>>> I thought it was simply a "normal" Xen paravirtualized guest kernel. ie
>>> any 'pv' guest is also a valid 'pvh' guest. Looking at the docs
>>>
>>>     https://wiki.xen.org/wiki/Xen_Project_Software_Overview#Guest_Types
>>>
>>> It appears I was wrong. It says a pvh guest kernel relies on hardware
>>> virt extensions for part of its work and paravirt for other parts. So
>>> really is a hybrid between pv and hvm.
>>
>> Right. The Xen wiki also has a good writeup about the various guest types
>>
>> https://wiki.xenproject.org/wiki/Understanding_the_Virtualization_Spectrum
>>
>>> With that in mind, we should indeed have a distinct OS type constant
>>> to express this.
>>
>> There have been some long threads in the various versions of this series
>> with a lot of waffling :-). I made a few attempts at summarizing what we
>> learned about PV vs PVH but could never build a strong case (at least in my
>> own head) for either of the two modeling approaches
>>
>> https://www.redhat.com/archives/libvir-list/2018-October/msg00214.html
>> https://www.redhat.com/archives/libvir-list/2018-October/msg00891.html
> 
> It has a bad name, but essentially you should consider "ostype" to
> refer to the   Hypervisor <-> Guest hardware ABI.

This is the key point I didn't consider :-(.

> Based on what I read, and your 2 links here, PV is clearly a different
> hardware ABI from PVH. Guest kernels needs different modifications for
> PV vs PVH.

Right.

> Sorry I didn't spot this sooner, and let this go off down the blind
> alley of switching based on machine type, when we should have used
> the ostype :-(

I've been around here long enough that I should have realized your key point 
above. Marek, I don't know what else to say but I'm sorry and will owe you many 
drinks of your choice should our paths cross...

Regards,
Jim