Re: [Qemu-devel] when we add EL2 to QEMU TCG ARM emulation and the virt board, should it default on or off?

[Laszlo Ersek]

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
>