From: Oliver Upton <oliver.upton@linux.dev>
To: Marc Zyngier <maz@kernel.org>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Alexandru Elisei <alexandru.elisei@arm.com>
Subject: Re: [PATCH] KVM: arm64: Fix S1/S2 combination when FWB==1 and S2 has Device memory type
Date: Tue, 26 Nov 2024 10:48:50 -0800 [thread overview]
Message-ID: <Z0YYEmeJhpJ2PaWf@linux.dev> (raw)
In-Reply-To: <86ed2yufdz.wl-maz@kernel.org>
On Tue, Nov 26, 2024 at 04:30:16PM +0000, Marc Zyngier wrote:
> On Tue, 26 Nov 2024 15:27:00 +0000,
> Oliver Upton <oliver.upton@linux.dev> wrote:
> >
> > On Mon, Nov 25, 2024 at 09:47:56AM +0000, Marc Zyngier wrote:
> > > The G.a revision of the ARM ARM had it pretty clear that HCR_EL2.FWB
> > > had no influence on "The way that stage 1 memory types and attributes
> > > are combined with stage 2 Device type and attributes." (D5.5.5).
> > >
> > > However, this wording was lost in further revisions of the architecture.
> > >
> > > Restore the intended behaviour, which is to take the strongest memory
> > > type of S1 and S2 in this case, as if FWB was 0. The specification is
> > > being fixed accordingly.
> >
> > Since you're already asking for a spec fix, could you mention that the
> > column headers in DDI0487K.a Table D8-95 are incorrect? MemAttr[1:0] is
> > used twice, although I believe the first column is actually MemAttr[3:2].
>
> That one has already been fixed as D22366, as described in the Known
> Issues document for version K.a (issue 07) [1].
Ah, right on. Thanks!
--
Best,
Oliver
next prev parent reply other threads:[~2024-11-26 18:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-25 9:47 [PATCH] KVM: arm64: Fix S1/S2 combination when FWB==1 and S2 has Device memory type Marc Zyngier
2024-11-26 15:27 ` Oliver Upton
2024-11-26 16:30 ` Marc Zyngier
2024-11-26 18:48 ` Oliver Upton [this message]
2024-11-26 15:59 ` Oliver Upton
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=Z0YYEmeJhpJ2PaWf@linux.dev \
--to=oliver.upton@linux.dev \
--cc=alexandru.elisei@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=suzuki.poulose@arm.com \
--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.