[PATCH v4 0/2] target/riscv: Fix PMP address alignment

[PATCH v4 0/2] target/riscv: Fix PMP address alignment

[Jay Chang]

This series fixes PMP address alignment to comply with the RISC-V
specification WARL (Write-Any, Read-Legal) semantics.

When configuring pmpcfg (TOR, NA4, or NAPOT) and pmpaddr, if the
value is smaller than the PMP granularity, it needs to be aligned
to the PMP granularity.

Changes in v4:
- Rebase riscv-to-apply.next

Changes in v3:
- Use ROUND_UP() macro for NAPOT address alignment

Changes in v2:
- Fixed commit message grammar ("it needs to be aligned")
- Use ROUND_DOWN() macro for TOR address alignment to improve
  code readability

Jay Chang (2):
  target/riscv: Align pmp size to pmp-granularity
  target/riscv: Use macros for PMP address alignment

 target/riscv/pmp.c | 22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

-- 
2.48.1

[PATCH v4 1/2] target/riscv: Align pmp size to pmp-granularity

[Jay Chang]

When configuring pmpcfg (TOR, NA4, or NAPOT) and pmpaddr, if the
value is smaller than the PMP granularity, it needs to be aligned
to the PMP granularity.

Signed-off-by: Jay Chang <jay.chang@sifive.com>
Reviewed-by: Frank Chang <frank.chang@sifive.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
---
 target/riscv/pmp.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/target/riscv/pmp.c b/target/riscv/pmp.c
index a71091a316..de2157c830 100644
--- a/target/riscv/pmp.c
+++ b/target/riscv/pmp.c
@@ -179,11 +179,12 @@ static bool pmp_write_cfg(CPURISCVState *env, uint32_t pmp_index, uint8_t val)
             }
             /*
              * When granularity g >= 1 (i.e., granularity > 4 bytes),
-             * the NA4 (Naturally Aligned 4-byte) mode is not selectable
+             * the NA4 (Naturally Aligned 4-byte) mode is not selectable.
+             * In this case, an NA4 setting is reinterpreted as a NAPOT mode.
              */
             if ((riscv_cpu_cfg(env)->pmp_granularity >
                 MIN_RISCV_PMP_GRANULARITY) && (a_field == PMP_AMATCH_NA4)) {
-                    return false;
+                    val |= PMP_AMATCH;
             }
             env->pmp_state.pmp[pmp_index].cfg_reg = val;
             pmp_update_rule_addr(env, pmp_index);
@@ -263,6 +264,11 @@ void pmp_update_rule_addr(CPURISCVState *env, uint32_t pmp_index)
         break;
 
     case PMP_AMATCH_NAPOT:
+        /* Bits [g-2:0] need to be all one to align pmp granularity */
+        if (g >= 2) {
+            this_addr |= ((1ULL << (g - 1ULL)) - 1ULL);
+        }
+
         pmp_decode_napot(this_addr, &sa, &ea);
         break;
 
-- 
2.48.1

[PATCH v4 2/2] target/riscv: Use macros for PMP address alignment

[Jay Chang]

Replace manual bit manipulation with alignment macros for better
readability:

- TOR: Use ROUND_DOWN() to clear lower bits
- NAPOT: Use ROUND_UP() to set lower bits

The behavior remains unchanged.

Signed-off-by: Jay Chang <jay.chang@sifive.com>
---
 target/riscv/pmp.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/target/riscv/pmp.c b/target/riscv/pmp.c
index de2157c830..238c7c5162 100644
--- a/target/riscv/pmp.c
+++ b/target/riscv/pmp.c
@@ -247,8 +247,9 @@ void pmp_update_rule_addr(CPURISCVState *env, uint32_t pmp_index)
     case PMP_AMATCH_TOR:
         /* Bits pmpaddr[G-1:0] do not affect the TOR address-matching logic. */
         if (g >= 1) {
-            prev_addr &= ~((1ULL << g) - 1ULL);
-            this_addr &= ~((1ULL << g) - 1ULL);
+            target_ulong granule = 1ULL << g;
+            prev_addr = ROUND_DOWN(prev_addr, granule);
+            this_addr = ROUND_DOWN(this_addr, granule);
         }
         if (prev_addr >= this_addr) {
             sa = ea = 0u;
@@ -266,7 +267,8 @@ void pmp_update_rule_addr(CPURISCVState *env, uint32_t pmp_index)
     case PMP_AMATCH_NAPOT:
         /* Bits [g-2:0] need to be all one to align pmp granularity */
         if (g >= 2) {
-            this_addr |= ((1ULL << (g - 1ULL)) - 1ULL);
+            target_ulong granule = 1ULL << (g - 1);
+            this_addr = ROUND_UP(this_addr + 1ULL, granule) - 1ULL;
         }
 
         pmp_decode_napot(this_addr, &sa, &ea);
@@ -641,13 +643,15 @@ target_ulong pmpaddr_csr_read(CPURISCVState *env, uint32_t addr_index)
         case PMP_AMATCH_TOR:
             /* Bit [g-1:0] read all zero */
             if (g >= 1 && g < TARGET_LONG_BITS) {
-                val &= ~((1ULL << g) - 1ULL);
+                target_ulong granule = 1ULL << g;
+                val = ROUND_DOWN(val, granule);
             }
             break;
         case PMP_AMATCH_NAPOT:
             /* Bit [g-2:0] read all one */
             if (g >= 2 && g < TARGET_LONG_BITS) {
-                val |= ((1ULL << (g - 1)) - 1ULL);
+                target_ulong granule = 1ULL << (g - 1);
+                val = ROUND_UP(val + 1ULL, granule) - 1ULL;
             }
             break;
         default:
-- 
2.48.1

Re: [PATCH v4 1/2] target/riscv: Align pmp size to pmp-granularity

[Philippe Mathieu-Daudé]

Hi,

On 18/5/26 09:07, Jay Chang wrote:
> When configuring pmpcfg (TOR, NA4, or NAPOT) and pmpaddr, if the
> value is smaller than the PMP granularity, it needs to be aligned
> to the PMP granularity.
> 
> Signed-off-by: Jay Chang <jay.chang@sifive.com>
> Reviewed-by: Frank Chang <frank.chang@sifive.com>
> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
> ---
>   target/riscv/pmp.c | 10 ++++++++--
>   1 file changed, 8 insertions(+), 2 deletions(-)


> @@ -263,6 +264,11 @@ void pmp_update_rule_addr(CPURISCVState *env, uint32_t pmp_index)
>           break;
>   
>       case PMP_AMATCH_NAPOT:
> +        /* Bits [g-2:0] need to be all one to align pmp granularity */
> +        if (g >= 2) {
> +            this_addr |= ((1ULL << (g - 1ULL)) - 1ULL);

deposit64() could be easier to read here.

> +        }
> +
>           pmp_decode_napot(this_addr, &sa, &ea);
>           break;
>   

Re: [PATCH v4 2/2] target/riscv: Use macros for PMP address alignment

[Philippe Mathieu-Daudé]

On 18/5/26 09:07, Jay Chang wrote:
> Replace manual bit manipulation with alignment macros for better
> readability:
> 
> - TOR: Use ROUND_DOWN() to clear lower bits
> - NAPOT: Use ROUND_UP() to set lower bits
> 
> The behavior remains unchanged.
> 
> Signed-off-by: Jay Chang <jay.chang@sifive.com>
> ---
>   target/riscv/pmp.c | 14 +++++++++-----
>   1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/target/riscv/pmp.c b/target/riscv/pmp.c
> index de2157c830..238c7c5162 100644
> --- a/target/riscv/pmp.c
> +++ b/target/riscv/pmp.c
> @@ -247,8 +247,9 @@ void pmp_update_rule_addr(CPURISCVState *env, uint32_t pmp_index)
>       case PMP_AMATCH_TOR:
>           /* Bits pmpaddr[G-1:0] do not affect the TOR address-matching logic. */
>           if (g >= 1) {
> -            prev_addr &= ~((1ULL << g) - 1ULL);
> -            this_addr &= ~((1ULL << g) - 1ULL);
> +            target_ulong granule = 1ULL << g;

Maybe better to directly use uint64_t, in preparation of
https://lore.kernel.org/qemu-devel/20260515180437.23620-1-anjo@rev.ng/

> +            prev_addr = ROUND_DOWN(prev_addr, granule);
> +            this_addr = ROUND_DOWN(this_addr, granule);
>           }

Re: [PATCH v4 2/2] target/riscv: Use macros for PMP address alignment

[Daniel Henrique Barboza]

On 5/18/2026 4:19 AM, Philippe Mathieu-Daudé wrote:
> On 18/5/26 09:07, Jay Chang wrote:
>> Replace manual bit manipulation with alignment macros for better
>> readability:
>>
>> - TOR: Use ROUND_DOWN() to clear lower bits
>> - NAPOT: Use ROUND_UP() to set lower bits
>>
>> The behavior remains unchanged.
>>
>> Signed-off-by: Jay Chang <jay.chang@sifive.com>
>> ---
>>   target/riscv/pmp.c | 14 +++++++++-----
>>   1 file changed, 9 insertions(+), 5 deletions(-)
>>
>> diff --git a/target/riscv/pmp.c b/target/riscv/pmp.c
>> index de2157c830..238c7c5162 100644
>> --- a/target/riscv/pmp.c
>> +++ b/target/riscv/pmp.c
>> @@ -247,8 +247,9 @@ void pmp_update_rule_addr(CPURISCVState *env, uint32_t pmp_index)
>>       case PMP_AMATCH_TOR:
>>           /* Bits pmpaddr[G-1:0] do not affect the TOR address-matching logic. */
>>           if (g >= 1) {
>> -            prev_addr &= ~((1ULL << g) - 1ULL);
>> -            this_addr &= ~((1ULL << g) - 1ULL);
>> +            target_ulong granule = 1ULL << g;
> 
> Maybe better to directly use uint64_t, in preparation of
> https://lore.kernel.org/qemu-devel/20260515180437.23620-1-anjo@rev.ng/

Can we please CC qemu-riscv@nongnu.org for the next version? This might
be the first time the RISC-V reviewers are made aware that this series
exists.  It surely is my first time :D


Cheers,
Daniel


> 
>> +            prev_addr = ROUND_DOWN(prev_addr, granule);
>> +            this_addr = ROUND_DOWN(this_addr, granule);
>>           }

Re: [PATCH v4 2/2] target/riscv: Use macros for PMP address alignment

[Anton Johansson via qemu development]

On 18/05/26, Daniel Henrique Barboza wrote:
> 
> 
> On 5/18/2026 4:19 AM, Philippe Mathieu-Daudé wrote:
> > On 18/5/26 09:07, Jay Chang wrote:
> > > Replace manual bit manipulation with alignment macros for better
> > > readability:
> > > 
> > > - TOR: Use ROUND_DOWN() to clear lower bits
> > > - NAPOT: Use ROUND_UP() to set lower bits
> > > 
> > > The behavior remains unchanged.
> > > 
> > > Signed-off-by: Jay Chang <jay.chang@sifive.com>
> > > ---
> > >   target/riscv/pmp.c | 14 +++++++++-----
> > >   1 file changed, 9 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/target/riscv/pmp.c b/target/riscv/pmp.c
> > > index de2157c830..238c7c5162 100644
> > > --- a/target/riscv/pmp.c
> > > +++ b/target/riscv/pmp.c
> > > @@ -247,8 +247,9 @@ void pmp_update_rule_addr(CPURISCVState *env, uint32_t pmp_index)
> > >       case PMP_AMATCH_TOR:
> > >           /* Bits pmpaddr[G-1:0] do not affect the TOR address-matching logic. */
> > >           if (g >= 1) {
> > > -            prev_addr &= ~((1ULL << g) - 1ULL);
> > > -            this_addr &= ~((1ULL << g) - 1ULL);
> > > +            target_ulong granule = 1ULL << g;
> > 
> > Maybe better to directly use uint64_t, in preparation of
> > https://lore.kernel.org/qemu-devel/20260515180437.23620-1-anjo@rev.ng/
> 
> Can we please CC qemu-riscv@nongnu.org for the next version? This might
> be the first time the RISC-V reviewers are made aware that this series
> exists.  It surely is my first time :D

That's on me, will do!:)

-- 
Anton Johansson
rev.ng Labs Srl.