Re: drop -enable-nesting

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2011-05-30 17:19, Avi Kivity wrote:
> On 05/30/2011 06:15 PM, Jan Kiszka wrote:
>> On 2011-05-30 17:10, Roedel, Joerg wrote:
>>>  On Mon, May 30, 2011 at 11:04:02AM -0400, Jan Kiszka wrote:
>>>>  On 2011-05-30 16:38, Nadav Har'El wrote:
>>>>>  On Mon, May 30, 2011, Jan Kiszka wrote about "drop -enable-nesting (was: [PATCH 3/7] cpu model bug fixes and definition corrections...)":
>>>>>>  On 2011-05-30 10:18, Roedel, Joerg wrote:
>>>>>>>  On Sat, May 28, 2011 at 04:39:13AM -0400, Jan Kiszka wrote:
>>>>>>>
>>>>>>>>  J�rg, how to deal with -enable-nesting in qemu-kvm to align behavior
>>>>>>>>  with upstream?
>>>>>>>
>>>>>>>  My personal preference is to just remove it. In upstream-qemu it is
>>>>>>>  enabled/disabled by +/-svm. -enable-nesting is just a historic thing
>>>>>>>  which can be wiped out.
>>>>>
>>>>>  "-enable-nesting" could remain as a synonym for enabling either VMX or SVM
>>>>>  in the guest, depending on what was available in the host (because KVM now
>>>>>  supports both nested SVM and nested VMX, but not SVM-on-VMX or vice versa).
>>>>
>>>>  Why? Once nesting is stable (I think SVM already is), there is no reason
>>>>  for an explicit enable. And you can always mask it out via -cpu.
>>>>
>>>>  BTW, what are the defaults for SVM right now in qemu-kvm and upstream?
>>>>  Enable if the modeled CPU supports it?
>>>
>>>  qemu-kvm still needs -enable-nesting, otherwise it is disabled. Upstream
>>>  qemu should enable it unconditionally (can be disabled with -cpu ,-svm).
>>
>> Then let's start with aligning qemu-kvm defaults to upstream? I guess
>> that's what the diff I was citing yesterday is responsible for.
>>
>> In the same run, -enable-nesting could dump a warning on the console
>> that this switch is obsolete and will be removed from future versions.
> 
> I think it's safe to drop -enable-nesting immediately.  Dan, does 
> libvirt make use of it?

I'm currently checking with some customer who played with Proxmox and
nesting if that stack was aware of the switch or accepted it only via a
side channel.

> 
>> For VMX, I would suggest to keep it off by default until it matured,
>> asking the user to issue -cpu ...,+vmx.
> 
> We should do that for svm as well (except for -cpu host or -cpu 
> something-with-svm).

I assume that's what upstream is doing. Maybe it has it was part of the
artificial default qemu64 model which is AMD based.

>  vmx will be kept disabled by the module option, 
> until it is deemed fit for general consumption.
> 

Yes, even better - no need for duplicate controls.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux