All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Dev Jain <dev.jain@arm.com>
Cc: Bradley Morgan <include@grrlz.net>,
	Oliver Upton <oupton@kernel.org>, Fuad Tabba <tabba@google.com>,
	Joey Gouly <joey.gouly@arm.com>,
	Steffen Eiden <seiden@linux.ibm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Quentin Perret <qperret@google.com>,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] KVM: arm64: Record whether pKVM stage 2 mapping is cacheable
Date: Sun, 05 Jul 2026 20:27:34 +0100	[thread overview]
Message-ID: <87echh6xuh.wl-maz@kernel.org> (raw)
In-Reply-To: <a3b2423e-d8bc-4713-90ef-5bfac7079834@arm.com>

On Sun, 05 Jul 2026 15:08:58 +0100,
Dev Jain <dev.jain@arm.com> wrote:
> 
> 
> 
> On 02/07/26 12:54 am, Bradley Morgan wrote:
> > pKVM keeps its own mapping list for stage 2 operations. Its flush path
> > uses that list directly, so it lost the PTE attribute check done by the
> > generic stage 2 walker.
> > 
> > Record whether a mapping is cacheable and skip cache maintenance for
> > mappings that are not cacheable.
> > 
> > Fixes: e912efed485a ("KVM: arm64: Introduce the EL1 pKVM MMU")
> 
> Is Fixes tag required? If I am reading correctly, Arm ARM says this:
> 
> "For VA-based cache maintenance instructions, the instruction operates on the
> caches regardless of the memory type and cacheability attributes marked for
> the memory address in the VMSA translation table entries. This means that
> the effects of the cache maintenance instructions can apply regardless of:
>   Whether the address accessed:
>     Is Normal memory or Device memory.
>     Has the Cacheable attribute or the Non-cacheable attribute."
> 
> So nothing goes wrong if we do dcache clean for non-cacheable
> memory.

Two things:

- having to perform CMOs for something that is not *expected* to be
  cacheable is both pointless and a contradiction of the intent

- what you quote is about the nature of the *mapping*, and not the
  memory that is being mapped. Cleaning a dirty cache line on an
  unsuspecting MMIO endpoint is never going to end nicely. Just have a
  try.

My reading of all this is that a fix indeed is required, and therefore
a Fixes tag *must* be present.

	M.

-- 
Jazz isn't dead. It just smells funny.


  parent reply	other threads:[~2026-07-05 19:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-01 19:24 [PATCH v4] KVM: arm64: Record whether pKVM stage 2 mapping is cacheable Bradley Morgan
2026-07-02  8:59 ` Marc Zyngier
2026-07-02 11:18   ` Leonardo Bras
2026-07-02 14:52     ` Bradley Morgan
2026-07-02 15:13       ` Leonardo Bras
2026-07-02 15:34       ` Marc Zyngier
2026-07-03 16:59         ` Bradley Morgan
2026-07-05 14:08 ` Dev Jain
2026-07-05 14:12   ` Bradley Morgan
2026-07-05 19:27   ` Marc Zyngier [this message]
2026-07-05 19:29     ` Bradley Morgan
2026-07-05 20:13       ` Marc Zyngier
2026-07-05 20:17         ` Bradley Morgan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87echh6xuh.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=dev.jain@arm.com \
    --cc=include@grrlz.net \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oupton@kernel.org \
    --cc=qperret@google.com \
    --cc=seiden@linux.ibm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.