From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49723) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c23do-0007mk-7Y for qemu-devel@nongnu.org; Wed, 02 Nov 2016 18:04:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c23dl-0002OL-01 for qemu-devel@nongnu.org; Wed, 02 Nov 2016 18:04:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57906) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c23dk-0002Ny-OZ for qemu-devel@nongnu.org; Wed, 02 Nov 2016 18:04:12 -0400 References: From: Laszlo Ersek Message-ID: <36764954-1ef5-ef26-731c-d23f8c914302@redhat.com> Date: Wed, 2 Nov 2016 23:04:07 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] when we add EL2 to QEMU TCG ARM emulation and the virt board, should it default on or off? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , QEMU Developers Cc: "Edgar E. Iglesias" , Andrew Jones On 11/01/16 18:16, Peter Maydell wrote: > I'm working on turning on EL2 support in our TCG ARM emulation, > and one area I'm not sure about is whether it should default to > on or off. > > We have a few precedents: > > For EL3 support: > * the CPU property is enabled by default but can be disabled by the board > * 'virt' defaults it to disabled, with a -machine secure=on property > which turns it on (barfing if KVM is enabled) and also does some other > stuff like wiring up secure-only memory and devices and making sure > the GIC has security enabled > * if the user does -cpu has_el3=yes things will probably not go > too well and that's unsupported > > For PMU support: > * the CPU property is enabled by default > * 'virt' defaults it to enabled (except for virt-2.6 and earlier) > * we do expect the user to be able to turn it on and off with > a -cpu pmu=yes/no option (and the board model changes behaviour > based on whether the CPU claims to have the feature) > > So what about EL2? Some background facts that are probably relevant: > * at the moment KVM can't support it, but eventually machines with > the nested virtualization hardware support will appear (this is > an ARMv8.3 feature), at which point it ought to work there too > * if you just enable EL2 then some currently working setups stop > working (basically any code that was written to assume it was > entered in EL1); notably this includes kvm-unit-tests (patches > pending from Drew that fix that). Linux is fine though as it > checks and handles both. > > Disabled-by-default has the advantage that (a) a command line > will work the same for TCG and KVM Definitely a bonus in my book. > and (b) nothing that used to > work will break. I consider this a requirement, sort of. Regressions are very very annoying (unless we can prove the previous command line was bogus to begin with, and just happened to work -- I don't think that applies in this case). > The disadvantage is that anybody who wants to > be able to run nested KVM will now have to specify a command line > option of some kind. Nested KVM is sophisticated / non-standard enough that one more tweak for utilizing it shouldn't be a problem. For example, considering the kvm_intel host module (yes, it's x86, but the parallel is obvious), it has an explicit parameter called "nested", which defaults to N. arch/x86/kvm/vmx.c: /* * If nested=1, nested virtualization is supported, i.e., guests may use * VMX and be a hypervisor for its own guests. If nested=0, guests may not * use VMX instructions. */ static bool __read_mostly nested = 0; module_param(nested, bool, S_IRUGO); Additionally, even with modprobe kvm_intel nested=1 I think the explicit setting -cpu MODEL,+vmx remains necessary. Thus, "disabled by default", please. Thanks Laszlo > > So: > (1) should we default on or off? (both at the board level, > and for the cpu object itself) > (2) directly user-set cpu property, or board property ? > > thanks > -- PMM >