[libvirt] [PATCH v1 0/3] libxl: nestedhvm support

[Joao Martins]

On 03/08/2017 03:07 PM, Daniel P. Berrange wrote:
> On Wed, Mar 08, 2017 at 03:09:11PM +0000, Joao Martins wrote:
>> On 03/08/2017 02:13 PM, Daniel P. Berrange wrote:
>>> On Wed, Mar 08, 2017 at 03:07:12PM +0100, Wim Ten Have wrote:
>>>> From: Wim ten Have <wim.ten.have at oracle.com>
>>>>
>>>> This patch enhances host-passthrough capability to advertise the
>>>> required vendor CPU virtualization feature which will be used to
>>>> enable 'nestedhvm' in the libxl driver.
>>>>
>>>> For Intel virtualization (VT-x)
>>>>     ..
>>>>   <cpu mode='host-passthrough'>
>>>>     <feature policy='require' name='vmx'/>
>>>>   </cpu>
>>>>
>>>> For AMD virtualization (AMD-V)
>>>>     ..
>>>>   <cpu mode='host-passthrough'>
>>>>     <feature policy='require' name='svm'/>
>>>>   </cpu>
>>>
>>> If using host-passthrough or host-model, and the host's CPU includes
>>> vmx or svm, then I would expecte nested-HVM to be enabled, without
>>> needing any extra <feature> flag in the XML. That would match the
>>> semantics used with the QEMU driver.
>>>
>>> The only time we would need to use <feature> is if using mode=custom
>>> along with a named CPU model which lacks vmx/svm flags.
>> Ah OK - I was kinda off unclear on that. So using host-passthrough should be
>> enough then. (while making sure libxl checks if host->cpu does have vmx or svm
>> in its features)
>>
>>> BTW, I wonder how hard it would be to wire up the libxl driver to use
>>> the CPU model infrastructure in src/cpu ? It feels a little odd to use
>>> XML <cpu mode='host-passthrough'/> if we're not then making sure it
>>> actually uses host-passthrough when configuring the guest.
>> While xen libxl do allow to mangle the cpuid, it is meant for disabling features
>> at this point. libxl follows a "host-model" first, meaning the default is to
>> expose as much as features as possible to the guest (depending on whether it's
>> PV or HVM). However, nested virt is a slightly special case since the toolstack
>> will do more than simply unmasking vmx/svm bits (actually within libxl, a sysctl
>> to Xen is performed to enable nested virt to the domain, in which case libxc
>> will handle any vendor specific bits). IOW, even when we improve libxl cpuid
>> policy management to the point we can wire up to libvirt cpu model
>> infrastruture, we would still need to handle the nestedhvm special case (which
>> btw this field would work even for ARM whenever supported).
> 
> Yep, I see. So with libxl using host-model by default, then
> 
>  - If the host CPU includes svm/vmx, turn on nested virt in the guest
>  - Allow use of <feature name="vmx" policy="disable"/> to block nested
>    virt in the guest, even if available in host CPU

Cool, thanks!

Joao