Received: by 2002:a05:7412:2a8c:b0:e2:908c:2ebd with SMTP id u12csp2762229rdh; Wed, 27 Sep 2023 11:54:09 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGp0YaBcuQ92/8wYPtRUlBBfVrtdP2OQlSFeFivxXYafVwj6m+p3qZOJywrm/6derAB/4sS X-Received: by 2002:a25:c845:0:b0:d7e:b89c:9919 with SMTP id y66-20020a25c845000000b00d7eb89c9919mr2613364ybf.1.1695840848956; Wed, 27 Sep 2023 11:54:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695840848; cv=none; d=google.com; s=arc-20160816; b=HUMC2RUjPpQB/dC37tT6Q8MeBID5zzjj6cswqIVi3QLfKkLPo77mNwoQ5Bjd8MdvYP 0ZuEYeOwoXGVYDtAigzxkLgzbP+UVOcU+mLEdLZ0tFJJ1Fl69wuaZMaE+cVHJRXenj1L L3cX4VRW9fVIKDp+64Mi6CP9TrhLtBeGbktxDd1gf6MIixhiPlcOHniBQIRl5stqH+QJ ajhpZa9yhJrE1le+FhpucslyUYf4GJomGss6GrAG44FobbjMf8O0pao/zZ0lMi9Ag/UR ZjQ8g+eaf/0dO5RA4OIyFXUlI4b019xit8DPCPUPoJ4nzpbD+c7lf9JL/SNJZvHRcXw5 jmxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:dkim-signature:date; bh=JsXW76YQkWWd3KcbYHc5LUjz+hl6N7YHm4uh3HGSGpg=; fh=9qF73/YLOhnsK699V4/Z+bn1WFjAgAfgLyH2lluwZlc=; b=QxlDl0wWCy6VnDHovLMhXySC2AqCWIMswu1lzuxcNHcTexcEr/qDs3FV0kUd1SE5U5 ZkJQPRYV1LcOlD8oH4InzLDMcA0qWIz8gH6nG+m5yeNl+zSSCNBRP35oph/gyjkifrNx OKSi6jVeSLLteeMFqK6YZKOtvD9ZNXsuR1Guqo2sv+JdFINAXxPkS0rLV7Hwuwawsi3l pDQ0tUHukIE0yls3HwjfhfXJQKbpK6GvqKsmRY6xD0ufjTiZkAvU/scrPswJAXQTvK/s au05WtE2JU797G1vcX0olD+c9nJWifrV3sekLdCVjJO82G+3ZqPp3xjASpDW+ZS7unDD Pp2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=LtQiyZ0u; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Return-Path: Received: from pete.vger.email (pete.vger.email. [23.128.96.36]) by mx.google.com with ESMTPS id y6-20020a63e246000000b00578eafd0826si16868253pgj.398.2023.09.27.11.54.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Sep 2023 11:54:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=LtQiyZ0u; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id 3F009808BE7D; Wed, 27 Sep 2023 01:29:27 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230251AbjI0I2z (ORCPT + 99 others); Wed, 27 Sep 2023 04:28:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230318AbjI0I23 (ORCPT ); Wed, 27 Sep 2023 04:28:29 -0400 Received: from out-199.mta1.migadu.com (out-199.mta1.migadu.com [95.215.58.199]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BF4D0180 for ; Wed, 27 Sep 2023 01:28:27 -0700 (PDT) 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9f731870-ed36-d2e4-378b-f7fbf338ebd6@arm.com> X-Migadu-Flow: FLOW_OUT X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Wed, 27 Sep 2023 01:29:27 -0700 (PDT) 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