On 16.09.21 14:24, Peter Maydell wrote: > On Wed, 15 Sept 2021 at 19:10, Alexander Graf <ag...@csgraf.de> wrote: >> Now that we have working system register sync, we push more target CPU >> properties into the virtual machine. That might be useful in some >> situations, but is not the typical case that users want. >> >> So let's add a -cpu host option that allows them to explicitly pass all >> CPU capabilities of their host CPU into the guest. >> >> Signed-off-by: Alexander Graf <ag...@csgraf.de> >> Acked-by: Roman Bolshakov <r.bolsha...@yadro.com> >> Reviewed-by: Sergio Lopez <s...@redhat.com> >> >> + /* >> + * A scratch vCPU returns SCTLR 0, so let's fill our default with the M1 >> + * boot SCTLR from https://github.com/AsahiLinux/m1n1/issues/97 >> + */ >> + ahcf->reset_sctlr = 0x30100180; >> + /* OVMF chokes on boot if SPAN is not set, so default it to on */ >> + ahcf->reset_sctlr |= 0x00800000; > Isn't that just an OVMF bug ? If you want this then you need to > convince me why this isn't just a workaround for a buggy guest.
I couldn't find anything in the ARMv8 spec that explicitly says "If you support PAN, SCTLR.SPAN should be 1 by default". It is RES1 for CPUs that do not implement PAN. Beware that for SPAN, "1" means disabled and "0" means enabled. So by making it 0 we are effectively enabling PAN support on behalf of the firmware, which sort-of goes against the whole idea of being backwards compatible, no? I'd say that OVMF behaves just fine by assuming PAN support is not enabled unless it does it explicitly itself. To make sure we get full agreement, I've added Ard to CC as well though :) Alex
