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 4CBC3332EB3 for ; Mon, 17 Nov 2025 15:21:31 +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=1763392892; cv=none; b=kJtdCsKEE07MdPpIEgWmzSMaH8hSMZaa29ykHBPygGDEo/M1IV3Q/PyCrp+Ayu3ffvX05NoA8GQpwK1syl6QDFNMri33W0mMIngLrHTUJh8Mztg3zx4Zbd8Abd6nNNxuMqspdFtnhzkVdf7tUmRdiZkmoBzoIVtmB+hWP7AHupc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763392892; c=relaxed/simple; bh=PVRxfGg1cEYxc9jw6OsJ9TgbyI7cJl91/PMDRKr5bL4=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=Nr584BVs+H5FIm6SIR8IYI1sdnpHNbDqBug/3HlCUj3h+r2a+/dcldYdxteRDXK9g/Sae4C0vzaVSm6FpVkpqCFvERV+cSqV41FfttA86orpITU7C3EX8ZAE5E3fGsmtL86n9Bdzz/IljRpcjc+cw6CotA2S3VmUMkfg/kpap8c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=k/d37biJ; 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="k/d37biJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA372C19424; Mon, 17 Nov 2025 15:21:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763392891; bh=PVRxfGg1cEYxc9jw6OsJ9TgbyI7cJl91/PMDRKr5bL4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=k/d37biJuARdKvYFnJYNN3pU9q56EaKjcn4q1OcewnuMICC4tZA+z/Ih/wxIjwsCf j3iKOpksYuMuQkkuupixaUKifbev4Bp/JPoKvFqaOIoXIkmY1UIRd3uGG06pJkFtFd Lc949A8jXGlQhAgHXyApg4cwK94iyJcVTwg6DQQAuXdrR0CzmFpNrz09KIGNHfmrI4 Yy9dT3pPPbAb3keVPJ7h4fCfIUgpOCJqt2gXXwaS+9v2G93kGX8n4I3YuBM5NLsAxa 74+mjJoRVv4nTfQd8PalbQ6GSSp7M+1cgFJN58/hfngq4xfui18qtF1tkKcrreBwYn nTslVAI22wiVg== 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 1vL12n-00000005s2C-29ij; Mon, 17 Nov 2025 15:21:29 +0000 Date: Mon, 17 Nov 2025 15:21:29 +0000 Message-ID: <86v7j8sn0m.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: kvmarm@lists.linux.dev, Joey Gouly , Suzuki K Poulose , Zenghui Yu Subject: Re: [PATCH 00/12] KVM: arm64: nv: Implement FEAT_XNX and FEAT_HAF In-Reply-To: <20251112183406.2118981-1-oupton@kernel.org> References: <20251112183406.2118981-1-oupton@kernel.org> 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=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: oupton@kernel.org, kvmarm@lists.linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Wed, 12 Nov 2025 18:33:54 +0000, Oliver Upton wrote: > > This series closes a couple of gaps between our shadow stage-2 > implementation and the architecture: > > FEAT_XNX - KVM doesn't make use of the feature for itself but this is > a rather low hanging fruit which entails expressing privileged and > unprivileged execute permissions in our pseudo-TLB I think this part looks good, no objection from my end. > > FEAT_HAF - This one is a bit more involved, requiring the PTW > implementations to atomically update descriptors in user memory to set > the Access Flag. I've made the implementation choice that AT > instructions also update the AF which was done to avoid evaluating the > access type in the PTW. This one needs a bit more work. There is a couple of amusing bugs that need addressing. Hopefully you can respin it shortly so that we can have this series in 6.19. > There's more work to be done for FEAT_HAFDBS (dirty state updates), > since updates to DBM are conditional based on the walk context. Lastly, > this is all horribly untested since I don't have an NV-capable machine > with FEAT_HAF that is easy to hack on. Although I do plan on adding some > selftests coverage soon. Yup, it looks like systems accessible to the common mortals don't have any of it (my QC box doesn't either). Oh well... Thanks, M. -- Without deviation from the norm, progress is not possible.