[PATCH] lib: sbi: Flush cache entries after writing PMP CSRs

[cp0613 at linux.alibaba.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