public inbox for opensbi@lists.infradead.org
 help / color / mirror / Atom feed
From: cp0613@linux.alibaba.com
To: anup@brainfault.org
Cc: samuel.holland@sifive.com, opensbi@lists.infradead.org
Subject: Re: [PATCH] lib: sbi: Flush cache entries after writing PMP CSRs
Date: Fri,  7 Nov 2025 16:13:49 +0800	[thread overview]
Message-ID: <20251107081349.1902-1-cp0613@linux.alibaba.com> (raw)
In-Reply-To: <CAK9=C2VJ2Sib35b8LNrm4tSwMJ2R3V2ae-B2euE85WTTk5Y82g@mail.gmail.com>

On 2025-10-31 03:49 AM, Anup Patel wrote:

> > Yes, agreed, the TLB entries must be tagged with the privilege mode, but that's
> > not the problem here. The problem has nothing at all to do with privilege mode
> > transitions, and nothing to do with executing code in S-mode, either. The bug
> > can be observed purely within the scope of the function calling
> > sbi_hart_map_saddr().
> 
> The reserved PMP entry under consideration is disabled while in S-mode
> before sbi_hart_map_saddr() and sbi_hart_unmap_saddr() so there is no
> way the reserved PMP entry impacts S-mode. In other words, we are
> not changing any PMP entry which impacts address ranges accessed by
> S-mode.
> 
> >
> > sbi_hart_map_saddr() rewrites a PMP range to allow M-mode access to some address
> > range that it previously did not have permission to access. The problem is that
> > this PMP change may not be observed until software executes a sfence.vma
> > covering at least this address range. So without this patch, it is
> > architecturally valid to receive an access fault when M-mode attempts to access
> > this address range (i.e. on the very next line of code after calling
> > sbi_hart_map_saddr()).
> 
> This is a fair point but we don't need to nuke the entire TLB. To address this,
> sfence.vma to a particular address range is sufficient. Plus, hfence is not
> required at all. I think this patch needs a complete re-write with
> clear comments
> for sfence.vma after PMP entry change in sbi_hart_map_saddr().
> 
> Regards,
> Anup

Thank you very much for your review. The issue you mentioned earlier, which slows
down many SBI calls that use shared memory, is indeed something that needs to be
considered. I will try to make further modifications based on your suggestions.

Thanks,
Pei

-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi

  reply	other threads:[~2025-11-07  8:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-04  9:54 [PATCH] lib: sbi: Flush cache entries after writing PMP CSRs cp0613
2025-10-20  4:36 ` Anup Patel
2025-10-29 22:32   ` Samuel Holland
2025-10-30  5:50     ` Anup Patel
2025-10-30 10:36       ` Samuel Holland
2025-10-31  3:49         ` Anup Patel
2025-11-07  8:13           ` cp0613 [this message]
2025-11-07  7:50         ` cp0613

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=20251107081349.1902-1-cp0613@linux.alibaba.com \
    --to=cp0613@linux.alibaba.com \
    --cc=anup@brainfault.org \
    --cc=opensbi@lists.infradead.org \
    --cc=samuel.holland@sifive.com \
    /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