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 B286034BA39 for ; Fri, 10 Oct 2025 10:31:47 +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=1760092307; cv=none; b=qrzDF6MAUKrO85EROE9QBXVcpySCyVqC5t1ZJ8ysoEkGrndiWZs0rvk6ZCcTwx7Syw3W0T7cgfLiPnSoCS1RZPZcNzx0IfZ8lMyTxo0X817qhHYUnMYVJI1c97g9HYe809NLooVb8vRW3RpfTStGw+xZuudh+I//MH/n5LfX2k4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760092307; c=relaxed/simple; bh=WrRWYWrLrzR/+HGJstCaY+cqsMP1PYa4QvWEDB8P1Mc=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=Vo4oPY0Zzlr72c1mdUK/fY0YM0aJ9MTP1sbbxDkKglotMPXIfxNeWam4h70MD80UCLLEHEy4BWkzJnnGBxUVujOYNK9wHf4vAQ8ItwfeB0LT2ztnEGFHEDYLzrKlTP4DBVAp6rhJ3NGBJcoENhaotw8qirrpk/194tHbDIBMLb4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QepyVKHE; 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="QepyVKHE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 42FF5C4CEF1; Fri, 10 Oct 2025 10:31:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1760092307; bh=WrRWYWrLrzR/+HGJstCaY+cqsMP1PYa4QvWEDB8P1Mc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=QepyVKHEqEN69ilmmt9qyXNVLWe7JAkMsY/MUkIXT9P3oRaFhF9FR4wb+teVvilRc T5wERyR0UYxms19iIQEXBIfCHtELpj5fLVCvCDS3oDHeZ8UKzZ7eioaWtErnRnHVn4 Bv/KZ/p0FHNJEGh3WMJtWsv6FMqIj1TQxEekq3Jdy6zESYc09+IKNsu5XP+QIF62wT m42okbUObD+4rqI+8T65LWs49pF8uwFfh9VRcybolrsweh25y51VOdGED73mEluirw BwqK/41Dk6T6Jd+VM4OAjButsO5Ifzu8Q7F4x5uLPf2aGH350/bhUtRf6OBRsGAchc 86deQiKTSq0HQ== 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.98.2) (envelope-from ) id 1v7APZ-0000000Csly-1c7P; Fri, 10 Oct 2025 10:31:45 +0000 Date: Fri, 10 Oct 2025 11:31:45 +0100 Message-ID: <86frbrxd2m.wl-maz@kernel.org> From: Marc Zyngier To: Jan Kotas Cc: Oliver Upton , "kvmarm@lists.linux.dev" Subject: Re: HCR_EL2 GET_ONE_REG value difference In-Reply-To: <2268E166-0EA0-4C9D-B1AF-EEECB48B926B@global.cadence.com> References: <47FBDCE7-F8D8-4071-93D8-E4E494D41F34@global.cadence.com> <86ikgnxfl0.wl-maz@kernel.org> <2268E166-0EA0-4C9D-B1AF-EEECB48B926B@global.cadence.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: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: jank@cadence.com, oliver.upton@linux.dev, kvmarm@lists.linux.dev X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Fri, 10 Oct 2025 10:51:52 +0100, Jan Kotas wrote: >=20 >=20 > > On 10 Oct 2025, at 11:37, Marc Zyngier wrote: > >=20 > > EXTERNAL MAIL > >=20 > >=20 > > On Fri, 10 Oct 2025 09:30:12 +0100, > > Jan Kotas wrote: > >>=20 > >> Hello, > >>=20 > >> During NV debugging I noticed a difference in HCR_EL2 value. > >>=20 > >> The value I get from accessing this register, using KVM_GET_ONE_REG: > >> 0x30480000000 > >=20 > > These bits are API, APK, E2H, RW. > >=20 > > When did you access this? After the vcpu has run? Before it has run? > > What NV configuration did you use? >=20 > Hi Marc, >=20 > I wanted to reproduce the conditions when I observed it. >=20 > I run the guest without the improved EL2 detection, > which was posted yesterday, in VHE mode.=20 > I=E2=80=99m investigating the place at which E2H detection happens, > just before an exception on ZCR_EL2. >=20 > >=20 > >>=20 > >> However, X1 value after executing mrs x1, hcr_el2 in guest: > >> 0x100030080000000 > >=20 > > You have ATA, API, APK, RW. Is that the *only* thing that has run in > > your guest? >=20 > I just booted the kernel directly without E2H0. >=20 > >=20 > >> I access both of these at the same place. > >=20 > > "at the same place"? What do you mean? One is accessed from host > > userspace, and the other from the guest. How can that be the same > > place? >=20 > By the same place I mean the same KVM_EXIT. > Without resuming vCPUs, at the same PC. >=20 > >=20 > >> I get the list of available registers from KVM_GET_REG_LIST. > >>=20 > >> I double checked my encoding, and it seems to be correct. > >> HCR_EL2 3, 4, 1, 1, 0 > >>=20 > >> I can check other registers, but I first wanted to check, if this expe= cted? > >> Is there something I=E2=80=99m missing, when accessing emulated regist= ers? > >=20 > > Could you please start by clarifying what you are doing? >=20 > I placed a HW breakpoint at the MRS instruction. > I did a single step, and then I checked X1 and HCR_EL2 values. > By calling GET_ONE_REG on both, I see different values. I'm very surprised that debug actually works, but hey, maybe I should admit that miracles can happen... ;-) The guest can write whatever it wants to the HCR_EL2 register. That's just a 64bit chunk of memory, and if it wants to write Pi to it, it can. Nothing the guest writes there will have any effect as long as it doesn't ERET to EL1 anyway. What GET_ONE_REG returns is the *sanitised* view of that register, after having applied RES0 and RES1 masks, as well as the constraints that are specific to your exact configuration. Since you are running without the patch that makes the two views consistent, your kernel is probably taking the wrong path, and configuring bits that have no meaning in that configuration and resulting in, amongst other things, E2H appearing to be 0 while GET_ONE_REG clearly tells you it is 1. M. --=20 Without deviation from the norm, progress is not possible.