On 12.02.2026 15:47, Oleksii Kurochko wrote:
>
> On 2/12/26 1:56 PM, Jan Beulich wrote:
>> On 12.02.2026 12:57, Oleksii Kurochko wrote:
>>> On 2/12/26 11:16 AM, Jan Beulich wrote:
>>>> On 10.02.2026 17:36, Oleksii Kurochko wrote:
>>>>> --- a/xen/arch/riscv/p2m.c
>>>>> +++ b/xen/arch/riscv/p2m.c
>>>>> @@ -1434,3 +1434,126 @@ struct page_info *p2m_get_page_from_gfn(struct
>>>>> p2m_domain *p2m, gfn_t gfn,
>>>>>
>>>>> return get_page(page, p2m->domain) ? page : NULL;
>>>>> }
>>>>> +
>>>>> +void p2m_ctxt_switch_from(struct vcpu *p)
>>>>> +{
>>>>> + if ( is_idle_vcpu(p) )
>>>>> + return;
>>>>> +
>>>>> + /*
>>>>> + * No mechanism is provided to atomically change vsatp and hgatp
>>>>> + * together. Hence, to prevent speculative execution causing one
>>>>> + * guest’s VS-stage translations to be cached under another guest’s
>>>>> + * VMID, world-switch code should zero vsatp, then swap hgatp, then
>>>>> + * finally write the new vsatp value what will be done in
>>>>> + * p2m_handle_vmenter().
>>>>> + */
>>>>> + p->arch.vsatp = csr_swap(CSR_VSATP, 0);
>>>>> +
>>>>> + /*
>>>>> + * Nothing to do with HGATP as it is constructed each time when
>>>>> + * p2m_handle_vmenter() is called.
>>>>> + */
>>>>> +}
>>>>> +
>>>>> +void p2m_ctxt_switch_to(struct vcpu *n)
>>>>> +{
>>>>> + if ( is_idle_vcpu(n) )
>>>>> + return;
>>>>> +
>>>>> + n->domain->arch.p2m.is_ctxt_switch_finished = false;
>>>> How can the context switch of a vCPU affect domain-wide state?
>>> It is wrong to have is_ctxt_switch_finished per domain, it should be
>>> vCPU field.
>>>
>>>>> + /*
>>>>> + * Nothing to do with HGATP or VSATP, they will be set in
>>>>> + * p2_handle_vmenter()
>>>>> + */
>>>> Why can this not be done here?
>>> As VMID should be calculated on VM enter.
>> And I didn't suggest to calculate a new one here.
>>
>>> We can update HGATP and VSATP here with VMID stored before in
>>> p2m_ctxt_switch_from(),
>>> but then it is possible when vmid_handle_vmenter() will be called before VM
>>> entry
>>> VMID could be changed and it will be needed again to update HGATP and VSATP
>>> what
>>> will lead to flushing of VS TLB twice (one in p2m_ctxt_switch_to() and
>>> another one
>>> in p2m_handle_vmenter()).
>> Is this a concern resulting from particular logic you expect to appear
>> in the window between context switch and entering the guest, or is this
>> merely an abstract concern?
>
> If we will have VS TLB flush unconditionally in VM entry then it is merely an
> abstract concern.
Why would we want to flush unconditionally?
> Otherwise, considering that speculation could happen between
> context switch and VM entry what could lead to that some entries were added to
> VS TLB flush with old VMID in the case if then in VM entry vCPU might receive
> new
> VMID.
I don't understand: Context switch leaves vsatp.MODE at zero. Nothing can end
up in the VS TLB in that case, aiui.
Jan
