From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 D2C5926ED4F; Thu, 25 Jun 2026 15:43:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782402219; cv=none; b=IIJ9OUJjkqzjqQOpD/cOPaSEd/U8/1hWnmPaKA6gXkmc3JX/+Q7dH39hzgD4iOB8l5aCHYEcPpJdHavUoSPyeDuPqjpsTw9bMS2PJl813inp0KT8B71PpQlGWxuRWeVNFB56loTxNnE0ktDBVJz8T0oBouRUqlys44e1IJcKVv8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782402219; c=relaxed/simple; bh=GTxRGfIofU69HdepXDcVaWOfr0ys4GXlJk8CRgWIm50=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=hfJA0OaMZxPA020rtTlPbq50H9rbBKY2DJHYDnS69o8l+p/g38eL8HzalfjcrH5v2pGc3fZQsOJiFvfJYrOBhmoSsicj7oHSfTd3sGCZ9V3UzIRJA8FDD7ZUb724THzrHFO0uheVirYwifKhEK/EhgQkuzkqC/0IkCE++9bvVGA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Z6OSVD9E; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z6OSVD9E" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 528FB1F000E9; Thu, 25 Jun 2026 15:43:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782402217; bh=zgckjcnTw2uZ7wwmfYqn2bQSr2oBXuMLJK0V5jCB+D8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Z6OSVD9ElFWcTDLX2eVYt0pt0QDvQt5D0ANOM4JgE/pezOsxyKRS23ITCPlQyuDlC m066zgdl56UtL0OTWryCbkGsU7Ei4iHppsCvFhukidbUL5x1NJknAPSp5yyMCxqLgW P4eGSB9EtpPvx4q5I6CwQgggjqQdYkLllj8AiGs/lgO4Ki4Hwjh5QxE1g7zf/D8mc+ mlLB5J9IFNX+3ERQo0Kzz6tj/atXZIGOOt7DPWqy03GTGs+RJJvfPHV6rgzTFURbxl y0RxtjXYZDK1iaQitiJYAMwDsA7EbwlHfmTOa1wt6NoZkezAQdrubPmqnZfaBE9Nn9 fcMuWRpN+FMGg== 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 1wcmEp-0000000G2My-1b7N; Thu, 25 Jun 2026 15:43:35 +0000 Date: Thu, 25 Jun 2026 16:43:34 +0100 Message-ID: <86echur5g9.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: sashiko-reviews@lists.linux.dev, kvmarm@lists.linux.dev Subject: Re: [PATCH v2 1/2] KVM: arm64: Only consider S1PTW a write fault if HA is set In-Reply-To: References: <20260624202446.1698535-1-oupton@kernel.org> <20260624202446.1698535-2-oupton@kernel.org> <20260624204025.519861F000E9@smtp.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, sashiko-reviews@lists.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 Wed, 24 Jun 2026 22:00:43 +0100, Oliver Upton wrote: > > On Wed, Jun 24, 2026 at 08:40:24PM +0000, sashiko-bot@kernel.org wrote: > > > + /* > > > + * The architecture sucks; assume that the S1PTW fetched for write if > > > + * HA is enabled at stage-1. Note that hardware updates to dirty state > > > + * and table AF are predicated on HA=1 (DDI0487 M.a D24.2.194; R_SNVTX). > > > + */ > > > + if (kvm_vcpu_abt_iss1tw(vcpu)) > > > + return effective_tcr_ha(vcpu); > > > > [Severity: High] > > Does unconditionally treating S1PTW faults as writes when HA is enabled break > > guests that use pre-populated page tables in read-only memslots? > > > > If a guest populates its page tables with the Access Flag already set, places > > them in an RO memslot, and enables HA in its TCR, the hardware only needs read > > access during a walk. Correct, this is a consequence of R_HDTRB. > > However, if a translation fault occurs, > > kvm_is_write_fault() will unconditionally evaluate to true because of > > effective_tcr_ha(). > > > > This will cause kvm_handle_guest_abort() to see a write fault on an RO memslot > > and inject a spurious Synchronous External Abort (SEA) into the guest, even > > though the hardware only needed to read the page table. Could we retain the > > conditional check for permission faults to avoid this? > > Gah, I tested with QEMU+EDK2 for this exact purpose but did so on an > implementation without HAFDBS. I've been chewing on that one for a bit, and came up with the following argument: - We're missing one of Read or Write because of L1's doing, and L1 needs to do *something* about it. We don't need to find out about HA in the guest, we just need to forward the fault (and it is probably enough to check that we're in a nested context). - We have checked that HA==1, derived from that that we need R+W, and we're missing the Write permission because the page is marked RO (assuming that KVM still maps with Read permission by default): - either it is "opportunistically" RO (dirty tracking, page never written to), and we flip it to RW, rince, repeat. - or it is hard-wired to RO at the memslot level, and the only possibility is that the PTW is trying to perform an atomic access (as per R_HDTRB), which we should be able to reject with an "Unsupported atomic hardware update fault". Thoughts? M. -- Without deviation from the norm, progress is not possible.