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

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