Re: [PATCH v2 01/17] xen/riscv: implement sbi_remote_hfence_gvma()

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

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