[PATCH 0/6] KVM: arm64: ... and FWB for all

[Marc Zyngier]

On Fri, 23 Jan 2026 12:22:58 +0000,
Alexandru Elisei <alexandru.elisei at arm.com> wrote:
> 
> Hi Marc,
> 
> On Mon, Jan 19, 2026 at 10:56:45AM +0000, Marc Zyngier wrote:
> > [Yes, you can tell what I was listening to]
> > 
> > Today, running in protected mode puts the host under it's own S2 with
> > FWB=0, even if the rest of the guests are running with FWB=1. The
> > rationale for this special-casing of the host is that we want the
> > combined attributes to actually reflect the ones exposed by S1.
> > 
> > We therefore use NormalCacheable (which is the weakest memory type) as
> > the default attributes at S2 so that S1 can only strengthen the final
> > memory type.
> > 
> > But there is no reason why we cannot achieve the same effect with
> > FWB. We normally use FWB to enforce cacheable memory from S2,
> > irrespective of S1. But it is possible to configure the S2 attributes
> > as "pass-through", so that the S1 attributes are always used.
> 
> Would you mind clarifying why FWB is preferable? Is it so that pkvm uses
> the same approach for configuring stage 2 for the host as for a guest? Or
> is it something else?

Having only one attribute encoding scheme to think about on a given
machine is vastly preferable, specially when you are debugging.
Additionally, FWB==0 may not be with us forever.

> > This small series implements that change, adding a flag that actually
> > describes what we are trying to do (instead of the NOFWB flag which is
> > pretty obscure), and fixes an interesting gotcha with CMOs.
> > Interestingly, CMOs never actually worked with NOFWB on an FWB-aware
> > platform...
> 
> Hmm... as far I can tell pkvm doesn't populate
> mm_ops->dcache_clean_inval_poc for host_mmu, so pKVM doesn't issue CMOs for
> the host s2, with or without these changes.

Yeah, I clearly was talking nonsense. I don't know how I came to this
silly conclusion.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.