On 6/23/25 4:39 PM, Jan Beulich wrote:
On 23.06.2025 16:31, Oleksii Kurochko wrote:
On 6/18/25 5:15 PM, Jan Beulich wrote:
On 10.06.2025 15:05, Oleksii Kurochko wrote:
Instruct the remote harts to execute one or more HFENCE.GVMA instructions,
covering the range of guest physical addresses between start_addr and
start_addr + size for all the guests.
Here and in the code comment: Why "for all the guests"? Under what conditions
would you require such a broad (guest) TLB flush?
Originally, it came from Andrew reply:
```
TLB flushing needs to happen for each pCPU which potentially has cached
a mapping.
In other arches, this is tracked by d->dirty_cpumask which is the bitmap
of pCPUs where this domain is scheduled.
CPUs need to flush their TLBs before removing themselves from
d->dirty_cpumask, which is typically done during context switch, but it
means that to flush the P2M, you only need to IPI a subset of CPUs.
```
Hmm, but the word "guest" doesn't even appear there. "Each pCPU" isn't quite
the same as "all guests".
Agree, it is just what SBI spec wording that...
pCPU here it is the first argument of sbi_remote_hfence_gvma(unsigned long
hart_mask, ...)
It is even more confusing as based on explaantion if RISC-V priv spec.,
hfence.gvma it is
used to flush G-stage (stage-2) TLB and hfence.vvma it is VS-stage (stage-1)
TLB flush.
~ Oleksii
