From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8BFFC78F32; Mon, 28 Apr 2025 21:42:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745876555; cv=none; b=JRYsfbieEzjL7av8JutSSH6goaK54oVl+tQ2thuCVnkFUe7Ymyn61X4mTJRhMhtgTLrEq7ADd5vwx0q+xZi4DVlOc3ZBRUuquocCoIC6ti+nUfYj45KYimfJso0cCMMHhPiOhJqtDAI/zp8GYQmoQDh2ZD94Vt4hpoF7LQNGeGo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745876555; c=relaxed/simple; bh=WDfKqbcsBrjOAyu4p9vHAjT/PfAev08KoKpJPLD9i6g=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=WTVzgw8fZS5bs3AfAWoh1UZi/02lHXK5V9HVH6Gapmidkg8JagJ1sGKaunFAem/HK8yWYrcBFQTANJ9P1Kqiu4decKNyVImC2+oqhAbRqo5wWjbz5IbN+8/5qEoFFcz+5ox9sjaETVKdFe6xIkULk4s/U9OgGkhCp3miKZD5IuA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=K8DqQ8pT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="K8DqQ8pT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F0ACFC4CEE4; Mon, 28 Apr 2025 21:42:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745876555; bh=WDfKqbcsBrjOAyu4p9vHAjT/PfAev08KoKpJPLD9i6g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=K8DqQ8pTgHsxIbVHJUCtzGRBdzSNsK0un9crwW/79lrTO1JE5Xb9tgfoHH2yZdw1F ZxaELOJXovD4OO0SCHzMCCUAnIsFPDCLVY8C1+xlArPeXD8P7WZxlt8RCyGmNzz/K5 U+h++XeehSrlF+afbTRahxEIgi6EzHi5NGoNaidiIjR90Jl1cq5jL30bHOuVw/MDkV a9QoUKx7cWrgH4G+P+8VxG9c9jpEcbAa1W18FlB/K9jBshIvhr8C3HeF4t5XZYPj7T fqeSwYg14HY/U+lpnLGr39Bulw6Ob9IurGyhNze8DCARq+as4I0XHSjLuyj8x33fMA 6tZGlOmrFrIFQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.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 1u9WFE-009gYN-O8; Mon, 28 Apr 2025 22:42:32 +0100 Date: Mon, 28 Apr 2025 22:42:24 +0100 Message-ID: <86jz74hsjj.wl-maz@kernel.org> From: Marc Zyngier To: Ganapatrao Kulkarni Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Joey Gouly , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Mark Rutland , Fuad Tabba , Will Deacon , Catalin Marinas Subject: Re: [PATCH v3 00/42] KVM: arm64: Revamp Fine Grained Trap handling In-Reply-To: <4e63a13f-c5dc-4f97-879a-26b5548da07f@os.amperecomputing.com> References: <20250426122836.3341523-1-maz@kernel.org> <4e63a13f-c5dc-4f97-879a-26b5548da07f@os.amperecomputing.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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: gankulkarni@os.amperecomputing.com, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, joey.gouly@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, mark.rutland@arm.com, tabba@google.com, will@kernel.org, catalin.marinas@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Mon, 28 Apr 2025 19:33:10 +0100, Ganapatrao Kulkarni wrote: > > Hi Marc, > > I am trying nv-next branch and I believe these FGT related changes are > merged. With this, selftest arm64/set_id_regs is failing. From initial > debug it seems, the register access of SYS_CTR_EL0, SYS_MIDR_EL1, > SYS_REVIDR_EL1 and SYS_AIDR_EL1 from guest_code is resulting in trap > to EL2 (HCR_ID1,ID2 are set) and is getting forwarded back to EL1, > since EL1 sync handler is not installed in the test code, resulting in > hang(endless guest_exit/entry). I don't see this problem here. At the very least, an EL1 Linux guest runs just fine accessing these registers. > > It is due to function "triage_sysreg_trap" is returning true. > > When guest_code is in EL1 (default case) it is due to return in below if. > > if (tc.fgt != __NO_FGT_GROUP__ && > (vcpu->kvm->arch.fgu[tc.fgt] & BIT(tc.bit))) { > kvm_inject_undefined(vcpu); > return true; > } > > IMO, Host should return the value of these sysreg read instead of > forwarding the trap to guest or something more to be added to > testcode? This is not a forward. It is an UNDEF. But none of these system registers are ever supposed to UNDEF. So something is setting the FGU bit mapped to HFGRTR_EL2.MIDR_EL1 to 1, and forces the register to UNDEF, assuming your analysis is correct. I'm afraid you'll have to dig a bit deeper. M. -- Without deviation from the norm, progress is not possible.