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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
