I wondered about this.
I first looked at using the CPU feature bit manipulation but that was,
at the time, completely unimplemented.
The CPU feature code also looked to be somewhat KVM centric.
In the end I went for the simple implementation because the complexity
of implementing the feature code would mean that I would need to become
a libvirt developer and I mostly just want to be a helpful libvirt user.
On 10/02/2015 08:18 AM, Daniel P. Berrange wrote:
On Thu, Oct 01, 2015 at 02:08:58PM -0400, Alvin Starr wrote:
> ---
> docs/schemas/domaincommon.rng | 10 ++++++++++
> src/conf/domain_conf.c | 6 ++++++
> src/conf/domain_conf.h | 2 ++
> src/libxl/libxl_conf.c | 35 +++++++++++++++++++++++++++++++++++
> 4 files changed, 53 insertions(+)
>
> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
> index f196177..402ff16 100644
> --- a/docs/schemas/domaincommon.rng
> +++ b/docs/schemas/domaincommon.rng
> @@ -4083,6 +4083,16 @@
> </element>
> </optional>
> <optional>
> + <element name="nestedhvm">
> + <empty/>
> + </element>
> + </optional>
> + <optional>
> + <element name="mask_svm_npt">
> + <empty/>
> + </element>
> + </optional>
> + <optional>
> <ref name="hyperv"/>
> </optional>
> <optional>
We really shouldn't be adding new schema for this. We should just
toggle enablement of nested SVM/VMX based on whether the <cpu>
model includes the <svm/> or <vmx/> feature flags. This is what
we already do on KVM for enabling this feature, and we'd want
Xen to work the same way IMHO.
Regards,
Daniel
--
Alvin Starr || voice: (905)513-7688
Netvel Inc. || Cell: (416)806-0133
alvin(a)netvel.net ||