On Tue, May 25, 2021 at 06:13:58PM +0100, Marc Zyngier wrote: > On Tue, 25 May 2021 16:14:32 +0100, > Will Deacon <will@xxxxxxxxxx> wrote: > > > > Document support for running 32-bit tasks on asymmetric 32-bit systems > > and its impact on the user ABI when enabled. > > > > Signed-off-by: Will Deacon <will@xxxxxxxxxx> > > --- > > .../admin-guide/kernel-parameters.txt | 3 + > > Documentation/arm64/asymmetric-32bit.rst | 154 ++++++++++++++++++ > > Documentation/arm64/index.rst | 1 + > > 3 files changed, 158 insertions(+) > > create mode 100644 Documentation/arm64/asymmetric-32bit.rst > > > > [...] > > > +KVM > > +--- > > + > > +Although KVM will not advertise 32-bit EL0 support to any vCPUs on an > > +asymmetric system, a broken guest at EL1 could still attempt to execute > > +32-bit code at EL0. In this case, an exit from a vCPU thread in 32-bit > > +mode will return to host userspace with an ``exit_reason`` of > > +``KVM_EXIT_FAIL_ENTRY``. > > Nit: there is a bit more to it. The vcpu will be left in a permanent > non-runnable state until KVM_ARM_VCPU_INIT is issued to reset the vcpu > into a saner state. Thanks, I'll add "and will remain non-runnable until re-initialised by a subsequent KVM_ARM_VCPU_INIT operation". Can the VMM tell that it needs to do that? I wonder if we should be setting 'hardware_entry_failure_reason' to distinguish this case. Will
