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 >
