[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: |
Laszlo Ersek |
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 23:04:07 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 |
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
>