qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]