From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2D30AC2B9F8 for ; Tue, 25 May 2021 18:11:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 03EE661404 for ; Tue, 25 May 2021 18:11:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229922AbhEYSNR (ORCPT ); Tue, 25 May 2021 14:13:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:38582 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229819AbhEYSNR (ORCPT ); Tue, 25 May 2021 14:13:17 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2B19F613F6; Tue, 25 May 2021 18:11:47 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1llbWr-003XfO-63; Tue, 25 May 2021 19:11:45 +0100 Date: Tue, 25 May 2021 19:11:44 +0100 Message-ID: <875yz6wun3.wl-maz@kernel.org> From: Marc Zyngier To: Will Deacon Cc: linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Catalin Marinas , Greg Kroah-Hartman , Peter Zijlstra , Morten Rasmussen , Qais Yousef , Suren Baghdasaryan , Quentin Perret , Tejun Heo , Johannes Weiner , Ingo Molnar , Juri Lelli , Vincent Guittot , "Rafael J. Wysocki" , Dietmar Eggemann , Daniel Bristot de Oliveira , kernel-team@android.com Subject: Re: [PATCH v7 22/22] Documentation: arm64: describe asymmetric 32-bit support In-Reply-To: <20210525172703.GA17250@willie-the-truck> References: <20210525151432.16875-1-will@kernel.org> <20210525151432.16875-23-will@kernel.org> <877djmwxbd.wl-maz@kernel.org> <20210525172703.GA17250@willie-the-truck> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, catalin.marinas@arm.com, gregkh@linuxfoundation.org, peterz@infradead.org, morten.rasmussen@arm.com, qais.yousef@arm.com, surenb@google.com, qperret@google.com, tj@kernel.org, hannes@cmpxchg.org, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, rjw@rjwysocki.net, dietmar.eggemann@arm.com, bristot@redhat.com, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Tue, 25 May 2021 18:27:03 +0100, Will Deacon wrote: > > On Tue, May 25, 2021 at 06:13:58PM +0100, Marc Zyngier wrote: > > On Tue, 25 May 2021 16:14:32 +0100, > > Will Deacon 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 > > > --- > > > .../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". Looks good. > 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. The VMM should be able to notice that something is amiss, as any subsequent KVM_RUN calls will result in -ENOEXEC being returned, and we document this as "the vcpu hasn't been initialized or the guest tried to execute instructions from device memory (arm64)". However, there is another reason to get a "FAILED_ENTRY", and that if we get an Illegal Exception Return exception when entering the guest. That one should always be a KVM bug. So yeah, maybe there is some ground to populate that structure with the appropriate nastygram (completely untested). M. diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h index 24223adae150..cf50051a9412 100644 --- a/arch/arm64/include/uapi/asm/kvm.h +++ b/arch/arm64/include/uapi/asm/kvm.h @@ -402,6 +402,10 @@ struct kvm_vcpu_events { #define KVM_PSCI_RET_INVAL PSCI_RET_INVALID_PARAMS #define KVM_PSCI_RET_DENIED PSCI_RET_DENIED +/* KVM_EXIT_FAIL_ENTRY reasons */ +#define KVM_ARM64_FAILED_ENTRY_NO_AARCH32_ALLOWED 0xBADBAD32 +#define KVM_ARM64_FAILED_ENTRY_INTERNAL_ERROR 0xE1215BAD + #endif #endif /* __ARM_KVM_H__ */ diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c index 6f48336b1d86..e97cd4de1fa7 100644 --- a/arch/arm64/kvm/handle_exit.c +++ b/arch/arm64/kvm/handle_exit.c @@ -262,6 +262,10 @@ int handle_exit(struct kvm_vcpu *vcpu, int exception_index) * have been corrupted somehow. Give up. */ run->exit_reason = KVM_EXIT_FAIL_ENTRY; + run->fail_entry.hardware_entry_failure_reason = (vcpu->arch.target == -1) ? + KVM_ARM64_FAILED_ENTRY_NO_AARCH32_ALLOWED : + KVM_ARM64_FAILED_ENTRY_INTERNAL_ERROR; + run->fail_entry.cpu = vcpu->cpu; return -EINVAL; default: kvm_pr_unimpl("Unsupported exception type: %d", -- Without deviation from the norm, progress is not possible.