From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-arm@nongnu.org, qemu-devel@nongnu.org,
Richard Henderson <richard.henderson@linaro.org>
Subject: Re: [PATCH] target/arm: Implement ARMv8.1-VMID16 extension
Date: Mon, 10 Feb 2020 12:23:40 +0000 [thread overview]
Message-ID: <875zge3a2b.fsf@zen.linaroharston> (raw)
In-Reply-To: <20200210120146.17631-1-peter.maydell@linaro.org>
Peter Maydell <peter.maydell@linaro.org> writes:
> The ARMv8.1-VMID16 extension extends the VMID from 8 bits to 16 bits:
>
> * the ID_AA64MMFR1_EL1.VMIDBits field specifies whether the VMID is
> 8 or 16 bits
> * the VMID field in VTTBR_EL2 is extended to 16 bits
> * VTCR_EL2.VS lets the guest specify whether to use the full 16 bits,
> or use the backwards-compatible 8 bits
>
> For QEMU implementing this is trivial:
> * we do not track VMIDs in TLB entries, so we never use the VMID
> field
Not currently but does the VMID allow you to have per-guest page table
caching? Last time I chatted to rth about potential performance wins we
discussed how easy it would be to support this in the softmmu now we
have indirect TLB lookups anyway. Given how much time is currently spent
expensively re-populating tables we could keep the last couple of id
tagged tables around for faster switching between sets of tables.
> * we treat any write to VTTBR_EL2, not just a change to the VMID field
> bits, as a "possible VMID change" that causes us to throw away TLB
> entries, so that code doesn't need changing
> * we allow the guest to read/write the VTCR_EL2.VS bit already
>
> So all that's missing is the ID register part: report that we support
> VMID16 in our 'max' CPU.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> Not something anybody's been asking for, but worthwhile as
> a step towards finishing off support for all the v8.1 extensions.
>
> target/arm/cpu64.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
> index 2d97bf45e1e..bf2cf278c03 100644
> --- a/target/arm/cpu64.c
> +++ b/target/arm/cpu64.c
> @@ -672,6 +672,7 @@ static void aarch64_max_initfn(Object *obj)
> t = cpu->isar.id_aa64mmfr1;
> t = FIELD_DP64(t, ID_AA64MMFR1, HPDS, 1); /* HPD */
> t = FIELD_DP64(t, ID_AA64MMFR1, LO, 1);
> + t = FIELD_DP64(t, ID_AA64MMFR1, VMIDBITS, 2); /* VMID16 */
> cpu->isar.id_aa64mmfr1 = t;
>
> /* Replicate the same data to the 32-bit id registers. */
I guess we can easily add the isar_feature_aa64_ functions when we need
them.
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
--
Alex Bennée
WARNING: multiple messages have this Message-ID (diff)
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-arm@nongnu.org,
Richard Henderson <richard.henderson@linaro.org>,
qemu-devel@nongnu.org
Subject: Re: [PATCH] target/arm: Implement ARMv8.1-VMID16 extension
Date: Mon, 10 Feb 2020 12:23:40 +0000 [thread overview]
Message-ID: <875zge3a2b.fsf@zen.linaroharston> (raw)
In-Reply-To: <20200210120146.17631-1-peter.maydell@linaro.org>
Peter Maydell <peter.maydell@linaro.org> writes:
> The ARMv8.1-VMID16 extension extends the VMID from 8 bits to 16 bits:
>
> * the ID_AA64MMFR1_EL1.VMIDBits field specifies whether the VMID is
> 8 or 16 bits
> * the VMID field in VTTBR_EL2 is extended to 16 bits
> * VTCR_EL2.VS lets the guest specify whether to use the full 16 bits,
> or use the backwards-compatible 8 bits
>
> For QEMU implementing this is trivial:
> * we do not track VMIDs in TLB entries, so we never use the VMID
> field
Not currently but does the VMID allow you to have per-guest page table
caching? Last time I chatted to rth about potential performance wins we
discussed how easy it would be to support this in the softmmu now we
have indirect TLB lookups anyway. Given how much time is currently spent
expensively re-populating tables we could keep the last couple of id
tagged tables around for faster switching between sets of tables.
> * we treat any write to VTTBR_EL2, not just a change to the VMID field
> bits, as a "possible VMID change" that causes us to throw away TLB
> entries, so that code doesn't need changing
> * we allow the guest to read/write the VTCR_EL2.VS bit already
>
> So all that's missing is the ID register part: report that we support
> VMID16 in our 'max' CPU.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> Not something anybody's been asking for, but worthwhile as
> a step towards finishing off support for all the v8.1 extensions.
>
> target/arm/cpu64.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
> index 2d97bf45e1e..bf2cf278c03 100644
> --- a/target/arm/cpu64.c
> +++ b/target/arm/cpu64.c
> @@ -672,6 +672,7 @@ static void aarch64_max_initfn(Object *obj)
> t = cpu->isar.id_aa64mmfr1;
> t = FIELD_DP64(t, ID_AA64MMFR1, HPDS, 1); /* HPD */
> t = FIELD_DP64(t, ID_AA64MMFR1, LO, 1);
> + t = FIELD_DP64(t, ID_AA64MMFR1, VMIDBITS, 2); /* VMID16 */
> cpu->isar.id_aa64mmfr1 = t;
>
> /* Replicate the same data to the 32-bit id registers. */
I guess we can easily add the isar_feature_aa64_ functions when we need
them.
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
--
Alex Bennée
next prev parent reply other threads:[~2020-02-10 12:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-10 12:01 [PATCH] target/arm: Implement ARMv8.1-VMID16 extension Peter Maydell
2020-02-10 12:01 ` Peter Maydell
2020-02-10 12:23 ` Alex Bennée [this message]
2020-02-10 12:23 ` Alex Bennée
2020-02-10 13:19 ` Peter Maydell
2020-02-10 13:19 ` Peter Maydell
2020-02-10 17:05 ` Richard Henderson
2020-02-12 6:33 ` Philippe Mathieu-Daudé
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=875zge3a2b.fsf@zen.linaroharston \
--to=alex.bennee@linaro.org \
--cc=peter.maydell@linaro.org \
--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 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.