[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] when we add EL2 to QEMU TCG ARM emulation and the virt
From: |
Edgar E. Iglesias |
Subject: |
Re: [Qemu-devel] when we add EL2 to QEMU TCG ARM emulation and the virt board, should it default on or off? |
Date: |
Wed, 2 Nov 2016 11:54:47 +0100 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Tue, Nov 01, 2016 at 05:16:59PM +0000, 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 and (b) nothing that used to
> work will break. 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.
>
> 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 ?
Hi Peter,
Good questions...
I wouldn't mind having a board level prop that defaults to off to keep
things somewhat consistent with current KVM and also the secure/EL3 props.
Best regards,
Edgar