[PATCH 0/3] target/arm, hw/arm/smmuv3: Advertise TTL and BBM features

[PATCH 0/3] target/arm, hw/arm/smmuv3: Advertise TTL and BBM features

[Peter Maydell]

These patches advertise support for the CPU FEAT_TTL and FEAT_BBM,
and for the SMMUv3.2-BBML2 which is the SMMU's equivalent to
FEAT_BBM).  For all of these, our current implementation is
sufficient to allow us to claim support, so these patches just set ID
bits.  The bulk of the patches is in the commit messages which
justify why this is OK...

To start with the simpler one, FEAT_TTL allows the guest to provide
an optional hint in TLB invalidate operations about which translation
table level holds the leaf entry for the address being invalidated. 
Since we don't need that information and we correctly ignore the
field that holds the TTL hint information, we can safely advertise
that we support FEAT_TTL.

FEAT_BBM is the complicated one.  The description in the Arm ARM of
the requirements of FEAT_BBM is admirably clear on the guarantees it
provides software, but slightly more obscure on what that means for
implementations.  The description of the equivalent SMMU feature in
the SMMU specification (IHI0070D.b section 3.21.1) is perhaps a bit
more detailed and includes some example valid implementation choices.

The informal summary of FEAT_BBM is that it is about permitting an OS
to switch a range of memory between "covered by a huge page" and
"covered by a sequence of normal pages" without having to engage in
the 'break-before-make' dance that has traditionally been necessary. 
The 'break-before-make' sequence is:

 * replace the old translation table entry with an invalid entry
 * execute a DSB insn
 * execute a broadcast TLB invalidate insn
 * execute a DSB insn
 * write the new translation table entry
 * execute a DSB insn

The point of this is to ensure that no TLB can simultaneously contain
TLB entries for the old and the new entry, which would traditionally
be UNPREDICTABLE (allowing the CPU to generate a TLB Conflict fault
or to use a random mishmash of values from the old and the new
entry).  FEAT_BBM level 2 says "for the specific case where the only
thing that changed is the size of the block, the TLB is guaranteed
not to do weird things even if there are multiple entries for an
address", which means that software can now do:

 * replace old translation table entry with new entry
 * DSB
 * broadcast TLB invalidate
 * DSB

As the SMMU spec notes, valid ways to do this include:

 * if there are multiple entries in the TLB for an address,
   choose one of them and use it, ignoring the others
 * if there are multiple entries in the TLB for an address,
   throw them all out and do a page table walk to get a new one

QEMU's page table walk implementation for Arm CPUs already meets the
requirements for FEAT_BBM level 2. When we cache an entry in our TCG
TLB, we do so only for the specific (non-huge) page that the address
is in, and there is no way for the TLB data structure to ever have
more than one TLB entry for that page. (We handle huge pages only in
that we track what part of the address space is covered by huge pages
so that a TLB invalidate operation for an address in a huge page
results in an invalidation of the whole TLB.) We ignore the Contiguous
bit in page table entries, so we don't have to do anything for the
parts of FEAT_BBM that deal with changes to the Contiguous bit.

Our SMMUv3 implementation  (unlike our CPU TLB) does allow multiple
TLB entries for an address, because the translation table level is
part of the SMMUIOTLBKey, and so our IOTLB hashtable can include
entries for the same address where the leaf was at different levels
(i.e.  both hugepage and normal page).  So here we rely on "pick one
of the multiple entries and ignore the rest" being a valid
implementation.

FEAT_BBM level 2 also requires that the nT bit in block descriptors
must be ignored. Since commit 39a1fd25287f5dece5 we do this for
the CPU; we always have done for the SMMU.

So for both SMMU and CPU we can advertise "level 2" BBM support.

(Note that we still can't yet advertise our SMMU as an SMMU v3.2,
because v3.2 requires support for the S2FWB feature, which we don't
yet implement. I might look at that when I do the CPU FEAT_S2FWB.)

thanks
-- PMM


Peter Maydell (3):
  target/arm: Advertise support for FEAT_TTL
  target/arm: Advertise support for FEAT_BBM level 2
  hw/arm/smmuv3: Advertise support for SMMUv3.2-BBML2

 docs/system/arm/emulation.rst | 2 ++
 hw/arm/smmuv3-internal.h      | 1 +
 hw/arm/smmuv3.c               | 1 +
 target/arm/cpu64.c            | 2 ++
 4 files changed, 6 insertions(+)

-- 
2.25.1

[PATCH 1/3] target/arm: Advertise support for FEAT_TTL

[Peter Maydell]

The Arm FEAT_TTL architectural feature allows the guest to provide an
optional hint in an AArch64 TLB invalidate operation about which
translation table level holds the leaf entry for the address being
invalidated.  QEMU's TLB implementation doesn't need that hint, and
we correctly ignore the (previously RES0) bits in TLB invalidate
operation values that are now used for the TTL field.  So we can
simply advertise support for it in our 'max' CPU.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 docs/system/arm/emulation.rst | 1 +
 target/arm/cpu64.c            | 1 +
 2 files changed, 2 insertions(+)

diff --git a/docs/system/arm/emulation.rst b/docs/system/arm/emulation.rst
index 520fd39071e..6ed2417f6fc 100644
--- a/docs/system/arm/emulation.rst
+++ b/docs/system/arm/emulation.rst
@@ -54,6 +54,7 @@ the following architecture extensions:
 - FEAT_TLBIOS (TLB invalidate instructions in Outer Shareable domain)
 - FEAT_TLBIRANGE (TLB invalidate range instructions)
 - FEAT_TTCNP (Translation table Common not private translations)
+- FEAT_TTL (Translation Table Level)
 - FEAT_TTST (Small translation tables)
 - FEAT_UAO (Unprivileged Access Override control)
 - FEAT_VHE (Virtualization Host Extensions)
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index eb44c05822c..ec2d159163f 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -839,6 +839,7 @@ static void aarch64_max_initfn(Object *obj)
     t = FIELD_DP64(t, ID_AA64MMFR2, CNP, 1); /* TTCNP */
     t = FIELD_DP64(t, ID_AA64MMFR2, ST, 1); /* TTST */
     t = FIELD_DP64(t, ID_AA64MMFR2, VARANGE, 1); /* FEAT_LVA */
+    t = FIELD_DP64(t, ID_AA64MMFR2, TTL, 1); /* FEAT_TTL */
     cpu->isar.id_aa64mmfr2 = t;
 
     t = cpu->isar.id_aa64zfr0;
-- 
2.25.1

[PATCH 2/3] target/arm: Advertise support for FEAT_BBM level 2

[Peter Maydell]

The description in the Arm ARM of the requirements of FEAT_BBM is
admirably clear on the guarantees it provides software, but slightly
more obscure on what that means for implementations.  The description
of the equivalent SMMU feature in the SMMU specification (IHI0070D.b
section 3.21.1) is perhaps a bit more detailed and includes some
example valid implementation choices. (The SMMU version of this
feature is slightly tighter than the CPU version: the CPU is permitted
to raise TLB Conflict aborts in some situations that the SMMU may
not. This doesn't matter for QEMU because we don't want to do TLB
Conflict aborts anyway.)

The informal summary of FEAT_BBM is that it is about permitting an OS
to switch a range of memory between "covered by a huge page" and
"covered by a sequence of normal pages" without having to engage in
the 'break-before-make' dance that has traditionally been
necessary. The 'break-before-make' sequence is:

 * replace the old translation table entry with an invalid entry
 * execute a DSB insn
 * execute a broadcast TLB invalidate insn
 * execute a DSB insn
 * write the new translation table entry
 * execute a DSB insn

The point of this is to ensure that no TLB can simultaneously contain
TLB entries for the old and the new entry, which would traditionally
be UNPREDICTABLE (allowing the CPU to generate a TLB Conflict fault
or to use a random mishmash of values from the old and the new
entry).  FEAT_BBM level 2 says "for the specific case where the only
thing that changed is the size of the block, the TLB is guaranteed
not to do weird things even if there are multiple entries for an
address", which means that software can now do:

 * replace old translation table entry with new entry
 * DSB
 * broadcast TLB invalidate
 * DSB

As the SMMU spec notes, valid ways to do this include:

 * if there are multiple entries in the TLB for an address,
   choose one of them and use it, ignoring the others
 * if there are multiple entries in the TLB for an address,
   throw them all out and do a page table walk to get a new one

QEMU's page table walk implementation for Arm CPUs already meets the
requirements for FEAT_BBM level 2. When we cache an entry in our TCG
TLB, we do so only for the specific (non-huge) page that the address
is in, and there is no way for the TLB data structure to ever have
more than one TLB entry for that page. (We handle huge pages only in
that we track what part of the address space is covered by huge pages
so that a TLB invalidate operation for an address in a huge page
results in an invalidation of the whole TLB.) We ignore the Contiguous
bit in page table entries, so we don't have to do anything for the
parts of FEAT_BBM that deal with changis to the Contiguous bit.

FEAT_BBM level 2 also requires that the nT bit in block descriptors
must be ignored; since commit 39a1fd25287f5dece5 we do this.

It's therefore safe for QEMU to advertise FEAT_BBM level 2 by
setting ID_AA64MMFR2_EL1.BBM to 2.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 docs/system/arm/emulation.rst | 1 +
 target/arm/cpu64.c            | 1 +
 2 files changed, 2 insertions(+)

diff --git a/docs/system/arm/emulation.rst b/docs/system/arm/emulation.rst
index 6ed2417f6fc..c3bd0676a87 100644
--- a/docs/system/arm/emulation.rst
+++ b/docs/system/arm/emulation.rst
@@ -9,6 +9,7 @@ the following architecture extensions:
 - FEAT_AA32HPD (AArch32 hierarchical permission disables)
 - FEAT_AA32I8MM (AArch32 Int8 matrix multiplication instructions)
 - FEAT_AES (AESD and AESE instructions)
+- FEAT_BBM at level 2 (Translation table break-before-make levels)
 - FEAT_BF16 (AArch64 BFloat16 instructions)
 - FEAT_BTI (Branch Target Identification)
 - FEAT_DIT (Data Independent Timing instructions)
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index ec2d159163f..2974cbc0d35 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -840,6 +840,7 @@ static void aarch64_max_initfn(Object *obj)
     t = FIELD_DP64(t, ID_AA64MMFR2, ST, 1); /* TTST */
     t = FIELD_DP64(t, ID_AA64MMFR2, VARANGE, 1); /* FEAT_LVA */
     t = FIELD_DP64(t, ID_AA64MMFR2, TTL, 1); /* FEAT_TTL */
+    t = FIELD_DP64(t, ID_AA64MMFR2, BBM, 2); /* FEAT_BBM at level 2 */
     cpu->isar.id_aa64mmfr2 = t;
 
     t = cpu->isar.id_aa64zfr0;
-- 
2.25.1

[PATCH 3/3] hw/arm/smmuv3: Advertise support for SMMUv3.2-BBML2

[Peter Maydell]

The Arm SMMUv3 includes an optional feature equivalent to the CPU
FEAT_BBM, which permits an OS to switch a range of memory between
"covered by a huge page" and "covered by a sequence of normal pages"
without having to engage in the traditional 'break-before-make'
dance. (This is particularly important for the SMMU, because devices
performing I/O through an SMMU are less likely to be able to cope with
the window in the sequence where an access results in a translation
fault.)  The SMMU spec explicitly notes that one of the valid ways to
be a BBM level 2 compliant implementation is:
 * if there are multiple entries in the TLB for an address,
   choose one of them and use it, ignoring the others

Our SMMU TLB implementation (unlike our CPU TLB) does allow multiple
TLB entries for an address, because the translation table level is
part of the SMMUIOTLBKey, and so our IOTLB hashtable can include
entries for the same address where the leaf was at different levels
(i.e. both hugepage and normal page). Our TLB lookup implementation in
smmu_iotlb_lookup() will always find the entry with the lowest level
(i.e. it prefers the hugepage over the normal page) and ignore any
others. 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
can validly advertise support for BBML level 2.

Note that we still can't yet advertise ourselves as an SMMU v3.2,
because v3.2 requires support for the S2FWB feature, which we don't
yet implement.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 hw/arm/smmuv3-internal.h | 1 +
 hw/arm/smmuv3.c          | 1 +
 2 files changed, 2 insertions(+)

diff --git a/hw/arm/smmuv3-internal.h b/hw/arm/smmuv3-internal.h
index d1885ae3f25..e9150a6ff33 100644
--- a/hw/arm/smmuv3-internal.h
+++ b/hw/arm/smmuv3-internal.h
@@ -56,6 +56,7 @@ REG32(IDR2,                0x8)
 REG32(IDR3,                0xc)
      FIELD(IDR3, HAD,         2, 1);
      FIELD(IDR3, RIL,        10, 1);
+     FIELD(IDR3, BBML,       11, 2);
 REG32(IDR4,                0x10)
 REG32(IDR5,                0x14)
      FIELD(IDR5, OAS,         0, 3);
diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
index 707eb430c23..74bc2e85ee4 100644
--- a/hw/arm/smmuv3.c
+++ b/hw/arm/smmuv3.c
@@ -259,6 +259,7 @@ static void smmuv3_init_regs(SMMUv3State *s)
 
     s->idr[3] = FIELD_DP32(s->idr[3], IDR3, RIL, 1);
     s->idr[3] = FIELD_DP32(s->idr[3], IDR3, HAD, 1);
+    s->idr[3] = FIELD_DP32(s->idr[3], IDR3, BBML, 2);
 
     /* 4K, 16K and 64K granule support */
     s->idr[5] = FIELD_DP32(s->idr[5], IDR5, GRAN4K, 1);
-- 
2.25.1

Re: [PATCH 0/3] target/arm, hw/arm/smmuv3: Advertise TTL and BBM features

[Richard Henderson]

On 4/26/22 09:04, Peter Maydell wrote:
> Peter Maydell (3):
>    target/arm: Advertise support for FEAT_TTL
>    target/arm: Advertise support for FEAT_BBM level 2
>    hw/arm/smmuv3: Advertise support for SMMUv3.2-BBML2

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>


r~

Re: [PATCH 3/3] hw/arm/smmuv3: Advertise support for SMMUv3.2-BBML2

[Eric Auger]

Hi Peter,

On 4/26/22 18:04, Peter Maydell wrote:
> The Arm SMMUv3 includes an optional feature equivalent to the CPU
> FEAT_BBM, which permits an OS to switch a range of memory between
> "covered by a huge page" and "covered by a sequence of normal pages"
> without having to engage in the traditional 'break-before-make'
> dance. (This is particularly important for the SMMU, because devices
> performing I/O through an SMMU are less likely to be able to cope with
> the window in the sequence where an access results in a translation
> fault.)  The SMMU spec explicitly notes that one of the valid ways to
> be a BBM level 2 compliant implementation is:
>  * if there are multiple entries in the TLB for an address,
>    choose one of them and use it, ignoring the others
>
> Our SMMU TLB implementation (unlike our CPU TLB) does allow multiple
> TLB entries for an address, because the translation table level is
> part of the SMMUIOTLBKey, and so our IOTLB hashtable can include
> entries for the same address where the leaf was at different levels
> (i.e. both hugepage and normal page). Our TLB lookup implementation in
> smmu_iotlb_lookup() will always find the entry with the lowest level
> (i.e. it prefers the hugepage over the normal page) and ignore any
> others. 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 you are confident about this, it looks good to me.
Reviewed-by: Eric Auger <eric.auger@redhat.com>

Eric




> can validly advertise support for BBML level 2.
>
> Note that we still can't yet advertise ourselves as an SMMU v3.2,
> because v3.2 requires support for the S2FWB feature, which we don't
> yet implement.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
>  hw/arm/smmuv3-internal.h | 1 +
>  hw/arm/smmuv3.c          | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/hw/arm/smmuv3-internal.h b/hw/arm/smmuv3-internal.h
> index d1885ae3f25..e9150a6ff33 100644
> --- a/hw/arm/smmuv3-internal.h
> +++ b/hw/arm/smmuv3-internal.h
> @@ -56,6 +56,7 @@ REG32(IDR2,                0x8)
>  REG32(IDR3,                0xc)
>       FIELD(IDR3, HAD,         2, 1);
>       FIELD(IDR3, RIL,        10, 1);
> +     FIELD(IDR3, BBML,       11, 2);
>  REG32(IDR4,                0x10)
>  REG32(IDR5,                0x14)
>       FIELD(IDR5, OAS,         0, 3);
> diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
> index 707eb430c23..74bc2e85ee4 100644
> --- a/hw/arm/smmuv3.c
> +++ b/hw/arm/smmuv3.c
> @@ -259,6 +259,7 @@ static void smmuv3_init_regs(SMMUv3State *s)
>  
>      s->idr[3] = FIELD_DP32(s->idr[3], IDR3, RIL, 1);
>      s->idr[3] = FIELD_DP32(s->idr[3], IDR3, HAD, 1);
> +    s->idr[3] = FIELD_DP32(s->idr[3], IDR3, BBML, 2);
>  
>      /* 4K, 16K and 64K granule support */
>      s->idr[5] = FIELD_DP32(s->idr[5], IDR5, GRAN4K, 1);

Re: [PATCH 3/3] hw/arm/smmuv3: Advertise support for SMMUv3.2-BBML2

[Peter Maydell]

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

Re: [PATCH 3/3] hw/arm/smmuv3: Advertise support for SMMUv3.2-BBML2

[Eric Auger]

On 4/28/22 11:26, Peter Maydell wrote:
> 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.

OK Thanks

Eric
>
>> If you are confident about this, it looks good to me.
>> Reviewed-by: Eric Auger <eric.auger@redhat.com>
> Thanks.
>
> -- PMM
>