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

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(a)oracle.com&gt; >>> >>> 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