Re: [PATCH 5/5] xen/riscv: add SFENCE.VMA after enabling paging

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 8/28/26 9:13 AM, Jan Beulich wrote:
> On 27.08.2026 18:53, Oleksii Kurochko wrote:
> > On 8/27/26 5:33 PM, Baptiste Le Duc wrote:
> > > --- a/xen/arch/riscv/riscv64/head.S
> > > +++ b/xen/arch/riscv/riscv64/head.S
> > > @@ -98,6 +98,7 @@ FUNC(turn_on_mmu)
> > >            srli    t1, t1, PAGE_SHIFT
> > >            or      t1, t1, t0
> > >            csrw    CSR_SATP, t1
> > ... ASID isn't used as we are in Bare mode.
> >
> > What am I missing?
> >
> > > +        sfence.vma
> > The one thing which possibly matters here, and could explain why
> > sfence.vma is needed, is:
> > ```
> > Implementations with virtual memory are permitted to perform address
> > translations speculatively and earlier than required by an explicit
> > memory access, and are permitted to cache them in address translation
> > cache structures—including possibly caching the identity mappings from
> > effective address to physical address used in Bare translation modes and
> > M-mode.
> > ```
> >
> > So the TLB could potentially be populated with identity mappings, and I
> > agree that it would be better to flush those.
> First: Does (or at least may) the TLB come into play in Bare mode? If not,
> there's nothing to invalidate.
In the quote from the spec I mentioned above it is written the answer is 
yes, the TLB (address-translation cache) absolutely can come into play 
in Bare mode.
> If so, the next question would be whether
> it's indeed ASID 0 which is (or again may be) used in such TLB entries.
I re-read the spec and ASID 0 will be really used even in Bare mode as 
to select MODE=Bare, software must write zero to the remaining fields of 
satp (bits 30–0 when SXLEN=32, or bits 59–0 when SXLEN=64) what 
automatically includes field ASID (so it will be zero).
And considering that idendentity mapping could be cached in TLB even in 
Bare mode they will taged with ASID = 0.
~ Oleksii