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 C52BCE810A4 for ; Wed, 27 Sep 2023 08:28:58 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=3ZgX+hJxLpZVrqEQxmBInwgzo2IT1JvQ/eTF0xhNOn8=; b=NAnU8u4KpZwrfG m3KaCFWJ6TNF8t0r0vIvGpdT7JNK4UCivr1OcIX64uOrDZs+idA8c6w6gyQch7CDcrYO/vXjwR5Vt br5ssEVWFeGhQPjxVN/22Xofqq8A4kWvsX4W2mpQbzrAuDC9CDhDCzeMSr2KrOsyTqVWN5UN9Om1P tAL2v1Fv7Mh4WPZmRRJ0UYiXgmXOOqPZwMYOV6qVi+93RxYYhoqllwOsYcgNX8oGs+2DslhgpOmFg kDT7hV1fdADUboThAb63UC/oDDsfGoGLJGZQgG6nxuafflh4Yc2WRGTBqsOnv4C1XLPUH9dTztVUk DNo7ooLx6qWY6D5Omrcw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qlPuM-000L4G-1q; Wed, 27 Sep 2023 08:28:34 +0000 Received: from out-200.mta1.migadu.com ([95.215.58.200]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qlPuJ-000L2J-06 for linux-arm-kernel@lists.infradead.org; Wed, 27 Sep 2023 08:28:33 +0000 Date: Wed, 27 Sep 2023 08:28:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1695803306; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JsXW76YQkWWd3KcbYHc5LUjz+hl6N7YHm4uh3HGSGpg=; b=LtQiyZ0uGVb8Rv3QD8dC2/G/zWWQ27meJIFYdXmORPcx9sijsUdn9u4ERK8b39FP/ukuy8 BCwdmxf2jvUydfPuh8l4+/VfBqpgi+cJEQg26cLsFreEJdOvIXD9YkQ4iqFwAnVgrLYM+Y LbqEHZKO/CXJnfFtvt7NvdbReUkAVB4= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Kristina Martsenko Cc: Marc Zyngier , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, 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 Message-ID: References: <20230922112508.1774352-1-kristina.martsenko@arm.com> <20230922112508.1774352-2-kristina.martsenko@arm.com> <87sf734ofv.wl-maz@kernel.org> <9f731870-ed36-d2e4-378b-f7fbf338ebd6@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9f731870-ed36-d2e4-378b-f7fbf338ebd6@arm.com> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230927_012831_476851_EEF5D47D X-CRM114-Status: GOOD ( 17.18 ) 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 On Mon, Sep 25, 2023 at 04:16:06PM +0100, Kristina Martsenko wrote: [...] > > 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? > > Yes, because we rollback the PC to the prologue instruction. We advance the > state machine so that the SS exception is taken immediately upon returning to > the guest at the prologue instruction. If we didn't advance it then we would > return to the guest, execute the prologue instruction, and then take the SS > exception on the middle instruction. Which would be surprising as userspace > would see the middle and epilogue instructions executed multiple times but not > the prologue. I agree with Kristina that taking the SS exception on the prologue is likely the best course of action. Especially since it matches the behavior of single-stepping an EL0 MOPS sequence with an intervening CPU migration. This behavior might throw an EL1 that single-steps itself for a loop, but I think it is impossible for a hypervisor to hide the consequences of vCPU migration with MOPS in the first place. Marc, I'm guessing you were most concerned about the former case where the VMM was debugging the guest. Is there something you're concerned about I missed? -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel