Re: [libvirt] [PATCH v3 2/6] libxl: do not enable nested HVM by mere presence of <cpu> element

On Tue, Dec 19, 2017 at 01:01:36PM +0000, Joao Martins wrote: Yes, the key point of libvirt is to apply consistent semantics across different drivers, so we should not diverge betweeen QEMU & Xen in this regard. 'host-passthrough' and 'host-model' are supposed to expose *every* feature that the host CPUs support (except for those few which the hypervisor may block due to ability to virtualize them). So 'host-passthrough' is correct to automatically expose vmx/svm, without requiring any extra <feature> element, and I don't think we can accept this patch. This has been the case for KVM for ages, even though it has been considered experimental. The only slight difference is that you can block use of svm/vmx at the host OS level via a kernel arg to the kvm modules. If you want to not expose svm/vmx to the guest, despite it being available in the host, then use feature policy=disble when configuring it. It depends on what semantics the Xen hypervisor provides. 'require' means expose the feature to the guest if it is supported by the host, but raise an error if the host doesn't support it. 'force' means expose the feature to the guest, even if the host does not support it at all. For HVM Xen guests there's no real distinction between these, as you can't run an HVM Xen guest without having hardware virt in your host. So for 'vmx' / 'svm' force/require are basically the same thing. For other CPU feature bits they are definitely different. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|