From: Peter Maydell <peter.maydell@linaro.org>
To: eric.auger@redhat.com
Cc: qemu-arm@nongnu.org,
Richard Henderson <richard.henderson@linaro.org>,
qemu-devel@nongnu.org
Subject: Re: [PATCH 3/3] hw/arm/smmuv3: Advertise support for SMMUv3.2-BBML2
Date: Thu, 28 Apr 2022 10:26:49 +0100 [thread overview]
Message-ID: <CAFEAcA9jzRuJJAXUckjD4L+LB6-UXBO2WDET2Y2YYQBBr62MLw@mail.gmail.com> (raw)
In-Reply-To: <4cd9121f-6c9f-f461-836f-a4b1ba8fedcd@redhat.com>
On Thu, 28 Apr 2022 at 09:37, Eric Auger <eric.auger@redhat.com> wrote:
> On 4/26/22 18:04, Peter Maydell wrote:
> > TLB invalidation correctly removes all TLB entries matching
> > the specified address or address range (unless the guest specifies the
> > leaf level explicitly, in which case it gets what it asked for). So we
> "
>
> unless the guest specifies the
> leaf level explicitly, in which case it gets what it asked for
>
> "
> This is the less obvious part as the spec says:
>
> "A TLB invalidation operation removes all matching TLB entries even if
> overlapping entries exist for a given
> address."
>
> I failed to find further precisions about the range invalidation & BBML.
If the invalidate says "level 2" then a TLB entry that wasn't
put in at level 2 doesn't match the TLB invalidate request and so
isn't removed (whether it overlaps a matching one at the same
address or not). This is defined as part of the behaviour of TLB
invalidates which specify a TTL, eg on page 142.
An implementation which did something like "find the first entry
that matches the address, then notice that it doesn't match
the specified TTL, so ignore it and do nothing" wouldn't be
correct. But "invalidate all the entries which match for
both address and TTL and ignore the ones which don't match
on TTL" is fine.
> If you are confident about this, it looks good to me.
> Reviewed-by: Eric Auger <eric.auger@redhat.com>
Thanks.
-- PMM
next prev parent reply other threads:[~2022-04-28 9:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-26 16:04 [PATCH 0/3] target/arm, hw/arm/smmuv3: Advertise TTL and BBM features Peter Maydell
2022-04-26 16:04 ` [PATCH 1/3] target/arm: Advertise support for FEAT_TTL Peter Maydell
2022-04-26 16:04 ` [PATCH 2/3] target/arm: Advertise support for FEAT_BBM level 2 Peter Maydell
2022-04-26 16:04 ` [PATCH 3/3] hw/arm/smmuv3: Advertise support for SMMUv3.2-BBML2 Peter Maydell
2022-04-28 8:37 ` Eric Auger
2022-04-28 9:26 ` Peter Maydell [this message]
2022-04-28 10:06 ` Eric Auger
2022-04-26 17:26 ` [PATCH 0/3] target/arm, hw/arm/smmuv3: Advertise TTL and BBM features Richard Henderson
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=CAFEAcA9jzRuJJAXUckjD4L+LB6-UXBO2WDET2Y2YYQBBr62MLw@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=eric.auger@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).