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 9A2621C5F27 for ; Fri, 10 Oct 2025 11:59:27 +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=1760097567; cv=none; b=ZJzKIffBuFGUh0fIJa3+SlkMrSVOQvZfsW+0ofGhLgGDCZXZC3wu4avt8OmajGMrGAQJv6F5z06TstSFHOeuDfN75jTHvOInZbuGGJfmUVa9F/YCvsL8u18ZOXARIRJBoQCkO/MoMQuVqlV/OjkZG5QoXbneAqZHtGjbb0I0gfQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760097567; c=relaxed/simple; bh=ddXvIR7mD4Ov7MBBEte7owEaebA/LyAnnsCarb6JVAw=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=X2zZqsD5prW0KyO3TSKZ2n5RthxsphwhTDbxqJ/wuWUjTGbnRiSisjNNBr9QYincSV5hoyzqgqJI9nibWi7TpXlS3w4NuYS8Bus0mAkeOrAmeTxB88gF2HBFa98UgIUNDB9WPvGUgcpXQ+C0oO0N3fyzAI9qgeCg9OxageLKlkw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VbZ/ocqk; 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="VbZ/ocqk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 390DCC4CEF1; Fri, 10 Oct 2025 11:59:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1760097567; bh=ddXvIR7mD4Ov7MBBEte7owEaebA/LyAnnsCarb6JVAw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=VbZ/ocqkYvwvhoq8l3rSCkaYPAPHK+sAck3qSoXf0yUVaBlTrGJnIz+ihcrc0jB/c V2L2ZdKnhbYbe3jTejgeSZE2fXEBk77NJLKtZtaHmefte7KATWw9EHaEpQ6fiNGXCi EoBLqpY6/gXO2N5DVgKH5dPSVRTaM6HS+FYgDwjB9TvmNrUJOdne/3iJFWTjJ07Pdt L50RWg++1peAk536IjW5YEzZ8zENL2iG04tdvqEeup7CAXYoqaE0L2SwwVWh7aB89o 0DEXeZxdror3NcANFy1dzJVOTBWobdfc0zDG+B9Oyf4i58LcQyFbfbreV4rQycKfWf RZmAzEaqxVuDw== 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 1v7BmO-0000000CtnI-3mJC; Fri, 10 Oct 2025 11:59:24 +0000 Date: Fri, 10 Oct 2025 12:59:24 +0100 Message-ID: <86ecrbx90j.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: <3E1DF662-DD3A-49B4-A67E-55E9658BAF52@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> <86frbrxd2m.wl-maz@kernel.org> <3E1DF662-DD3A-49B4-A67E-55E9658BAF52@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 11:59:45 +0100, Jan Kotas wrote: >=20 >=20 > > On 10 Oct 2025, at 12:31, Marc Zyngier wrote: > >=20 > > EXTERNAL MAIL > >=20 > >=20 > > 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 ex= pected? > >>>> Is there something I=E2=80=99m missing, when accessing emulated regi= sters? > >>>=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. > >=20 > > I'm very surprised that debug actually works, but hey, maybe I should > > admit that miracles can happen... ;-) >=20 > Great, I gave some positive feedback for once. :) Hey, there's no bad feedback, and your contribution is greatly appreciated. >=20 > > 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. > >=20 > > 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. > >=20 > > 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. >=20 > I got a feeling it will be something like this. >=20 > Maybe it would be useful to have a capability/flag > for GET_ONE_REG to get non-sanitized values? GET_ONE_REG is the save/restore interface. It is there to present architecturally correct information that can be restored to another machine. Having non-sanitised information would potentially prevent that. > Or a way for a VMM to access the raw NV2 memory? The whole point of this sanitisation is that there should be no way to obtain bad data from within KVM, even if the guest messes things up. Also, see below. > I=E2=80=99m just wondering, if Guest does something unexpected, > debugging it, may be harder, if a user sees different stuff than SW. This sort of problems exists on real HW already. If a bit is RES1 in the architecture, it doesn't mean that this bit is always 1. It means it is interpreted as 1 by the HW, but the bit could be set to any value and read as such. And that's exactly what we have here. SW writes 0 to E2H, and that's what you read from the register in the context of the guest itself. But GET_ONE_REG shows you how the "HW" interprets this bit, and that is where having the two views is actually valuable: different values are likely to result in different behaviours. KVM gives you the tool to see what both the guest programs (debug or access to the GPR using GET_ONE_REG), and how KVM interpret the programmed value (access to HCR_EL2 using GET_ONE_REG). Given that, my take is that what we have today is not only correct, but actually the desirable behaviour. Thanks, M. --=20 Without deviation from the norm, progress is not possible.