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

["Alex Bennée" <alex.bennee@linaro.org>]

Laszlo Ersek <lersek@redhat.com> writes:

> 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.

I think if we had a board model other than virt for aarch64 then it
would make sense to behave as close to the real hardware as possible.
However as virt is the default model and is intended for virtualisation
I'd also side with el2 being off by default.

If we ever get an SBSA model then I would expect that to start in as
high a privilege level as it should.

--
Alex Bennée