[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] target/riscv: Smepmp: Skip applying default rules when addre

From: LIU Zhiwei
Subject: Re: [PATCH] target/riscv: Smepmp: Skip applying default rules when address matches
Date: Mon, 13 Feb 2023 12:22:38 +0800
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1

On 2023/2/9 13:52, Himanshu Chauhan wrote:
When MSECCFG.MML is set, after checking the address range in PMP if the
asked permissions are not same as programmed in PMP, the default
permissions are applied. This should only be the case when there
is no matching address is found.

This patch skips applying default rules when matching address range
is found. It returns the index of the match PMP entry.

fixes: 824cac681c3 (target/riscv: Fix PMP propagation for tlb)

Signed-off-by: Himanshu Chauhan <hchauhan@ventanamicro.com>
  target/riscv/pmp.c | 9 ++++++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/target/riscv/pmp.c b/target/riscv/pmp.c
index d85ad07caa..0dfdb35828 100644
--- a/target/riscv/pmp.c
+++ b/target/riscv/pmp.c
@@ -446,9 +446,12 @@ int pmp_hart_has_privs(CPURISCVState *env, target_ulong 
- if ((privs & *allowed_privs) == privs) {
-                ret = i;
-            }
+            /*
+             * If matching address range was found, the protection bits
+             * defined with PMP must be used. We shouldn't fallback on
+             * finding default privileges.
+             */
+            ret = i;

Notice the return value is the matching rule index, which includes

1) the address range is matching.

2) the permission of the PMP rule and the memory access type are matching.

So we can't simply remove the second check.  I think the right fix is:

           if ((privs & *allowed_privs) == privs) {
                ret = i;
 -         }
 +         } else {
 +              ret = -2;
 +         }

The -2 return value avoids finding the default privileges. And it implies no 
matching rule is found.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]