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@xxxxxxxxxx> >>>> >>>> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
