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

[Jim Fehlig]

On 10/18/18 11:35 AM, Marek Marczykowski-Górecki 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?
> 
> I don't see a problem - each guest block represent set of possible
> configurations. Given the current structure, you could also ask "is
> the os_type for arch=x86_64 a xen or a hvm?". Both are valid, with
> possibly different set of features available. And the same goes for
> xenpv and xenpvh machines.

Right, it is not a problem. I've not been super confident in our modeling choice 
and keep coming up with lame reasons while VIR_DOMAIN_OSTYPE_XENPVH might be a 
better approach. But it is time for me to stop talking in circles and commit 
this series. VIR_DOMAIN_OSTYPE_XENPV and machine xenpvh still feels like the 
best approach and no one has flat out objected to that. We can always adjust the 
capabilities reporting later if we feel there is a better way to do it.

> Actually, I see qemu had similar problem as we have now with some features
> being specific to some machine value - maxCpus. And as solution, it was
> put in machine's attributes. But I think this approach is short-sighted.

Agreed, we can't just keep adding attributes. Seems a better approach would be 
<features> for each <machine>, but that is beyond the scope of this series.

Regards,
Jim