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(a)netvel.net ||