I have been looking at this once again and thinking about this whole
implementation.
I can agree with Daniel's assesment of the SVM/NPT bit setting but the
nested_hvm feature does not exist at all in KVM at the libvirt level/
I could be wrong but when I last looked nested hvm could only be
enabled/disabled in KVM at boot time and not on a per VM basis.
What is the accepted policy on features that are only available in a
single VM engine?
I could remove the SVM/NPT bit twidling and resbumit the patch if it is
likely to go somewhere?
On 10/02/2015 02:44 PM, Alvin Starr wrote:
I agree that it needs to be done the right way.
I am willing to help where I can but my basic knowledge of the code is
badly lacking so there is no reasonable way for me to contribute in a
significant way.
I am ok keeping my own hacks to the code that let me work along on my
projects and hope that some day this will get fixed.
On 10/02/2015 10:03 AM, Daniel P. Berrange wrote:
On Fri, Oct 02, 2015 at 09:50:26AM -0400, Alvin Starr wrote:
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.
Yep, I can certainly understand that POV. Unfortunately I think in this
case we really do need to do it the right way. IIUC, Xen does indeed
allow
the CPUID mask to be configured, so it ought to be possible to map from
the libvirt XML to the CPUID mask format. It would certainly be a
non-negligble
bit of work though.
Regards,
Daniel
--
Alvin Starr || voice: (905)513-7688
Netvel Inc. || Cell: (416)806-0133
alvin@xxxxxxxxxx ||
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list