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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B67A0CE7A8A for ; Sun, 24 Sep 2023 14:49:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ThZ6a7kxSnqVUXwsXhiZSR92TPfm5WCgxT2HKJKZ8Pk=; b=Yc9H1o7/kalJqn EJT3LGlHwVLdpN3SqvfaVAiCUtRnLUfB90qzDkTuF3z1Dg7TW6tZ8zFgnZ9ucoardvZ/Rbg2JSDfZ prTb0sO8RKPqYX3szMj53Mp08nIQ4eKR4EUr4QAPObIZg2cEv9iCuS4fFYgapHTkXgUHtX+IdV8ju Db0cJl+0ew9yS0VTTy/pqPA84RzLuHeVluuQYZyCw+M3AMrYho8wpwH/7lCKqfJBZBFhYZUarXcM6 imQFaMuu6vgyQnNuLgKNvVKQWTOx1ePWUH62FrOeNJLipfnwAh1GlmrD8mzPCIJc7lJJG64shVbxO gjcu9/PBco5aZMotMx8g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qkQPc-00CNhv-2n; Sun, 24 Sep 2023 14:48:44 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qkQPa-00CNhE-15 for linux-arm-kernel@lists.infradead.org; Sun, 24 Sep 2023 14:48:43 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id D4228B80AF6; Sun, 24 Sep 2023 14:48:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32B1BC433C7; Sun, 24 Sep 2023 14:48:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695566920; bh=5wwQymIM9y0KKXNvNJLppJrlGUb4t1sAROPS7agfkPc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=cB7nBRYxoQEcOuEzX2MFVO4aH9E2xJU/UztZrurs5gb6lfk6vH19Pi6chl6oSO1fc gUtruyY9zejUyaMrM/Jv7mbVHB+zGK1WCUmM0Q+FHKQQKuvIhCMFLQIgOnzajwc46Z fj+081NSxWnVGI/teLzqhrghCu4L+xFehJzjEH/yx4CNlunQKAYBecJptBoVv0Uwyg QQq4h+1i/rM74zxvwuGUf8cI+k+Hdhzn8sNSsNtkB1/4dveHJeg+ChfJQCPhjUkql7 wUXN9p/AdJDCqlOPzCZ2eRQzA+nF2u1BixE0Gtm/eHQ/gBwyjeH+atod755ufJW2HU mH8giEIxTtNlQ== Received: from [85.255.234.76] (helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1qkQPV-00FiVl-MD; Sun, 24 Sep 2023 15:48:37 +0100 Date: Sun, 24 Sep 2023 15:48:36 +0100 Message-ID: <87sf734ofv.wl-maz@kernel.org> From: Marc Zyngier To: Kristina Martsenko Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Oliver Upton , James Morse , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Vladimir Murzin , Colton Lewis , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/2] KVM: arm64: Add handler for MOPS exceptions In-Reply-To: <20230922112508.1774352-2-kristina.martsenko@arm.com> References: <20230922112508.1774352-1-kristina.martsenko@arm.com> <20230922112508.1774352-2-kristina.martsenko@arm.com> 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/28.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 85.255.234.76 X-SA-Exim-Rcpt-To: kristina.martsenko@arm.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, oliver.upton@linux.dev, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, vladimir.murzin@arm.com, coltonlewis@google.com, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230924_074842_662556_CE01D60B X-CRM114-Status: GOOD ( 24.94 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Kristina, On Fri, 22 Sep 2023 12:25:07 +0100, Kristina Martsenko wrote: > > An Armv8.8 FEAT_MOPS main or epilogue instruction will take an exception > if executed on a CPU with a different MOPS implementation option (A or > B) than the CPU where the preceding prologue instruction ran. In this > case the OS exception handler is expected to reset the registers and > restart execution from the prologue instruction. > > A KVM guest may use the instructions at EL1 at times when the guest is > not able to handle the exception, expecting that the instructions will > only run on one CPU (e.g. when running UEFI boot services in the guest). > As KVM may reschedule the guest between different types of CPUs at any > time (on an asymmetric system), it needs to also handle the resulting > exception itself in case the guest is not able to. A similar situation > will also occur in the future when live migrating a guest from one type > of CPU to another. > > Add handling for the MOPS exception to KVM. The handling can be shared > with the EL0 exception handler, as the logic and register layouts are > the same. The exception can be handled right after exiting a guest, > which avoids the cost of returning to the host exit handler. > > Similarly to the EL0 exception handler, in case the main or epilogue > instruction is being single stepped, it makes sense to finish the step > before executing the prologue instruction, so advance the single step > state machine. What is the rationale for advancing the state machine? Shouldn't we instead return to the guest and immediately get the SS exception, which in turn gets reported to userspace? Is it because we rollback the PC to a previous instruction? In the latter case, won't userspace see multiple SS exceptions for the middle instruction if trapping from the epilogue? This would be a bit surprising, to say the least. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel