[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 2/2] xen/riscv: add p2m context switch handling for VSATP and HGATP
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
- Date: Thu, 12 Feb 2026 17:49:47 +0100
- Cc: Romain Caritey <Romain.Caritey@xxxxxxxxxxxxx>, Alistair Francis <alistair.francis@xxxxxxx>, Connor Davis <connojdavis@xxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Thu, 12 Feb 2026 16:49:58 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 2/12/26 5:20 PM, Jan Beulich wrote:
On 12.02.2026 17:16, Oleksii Kurochko wrote:
On 2/12/26 4:42 PM, Jan Beulich wrote:
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?
To guarantee that a guest sees a clean switch with no possibilities of
using a stale entry. For example, if VMID changed between context switch
and VM entry we want to have flush, but considering your reply here ...
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
... we just have different implementation in mind for p2m_ctxt_switch_to().
I thought that your suggestion is to set both HGATP and VSATP in
p2m_ctx_switch_to()
while calculate VMID in p2m_handle_vmenter() (with potential update of HGATP
and VSATP
if needed) and with such approach VSATP won't be zero after p2m_ctx_switch_to()
and
speculation could happen between context switch and VM entry.
So just to clarify your expectations are:
So just to clarify from my side that I don't have any expectations; I
merely want to suggest to start with as simple a model as possible,
for its correctness to be easy to prove.
Got you. Then it seems like the easiest approach is to follow what is in this
patch until ...
1. p2m_ctxt_switch_from(p):
p.vsatp = VSATP
VSATP = 0
2. p2m_ctxt_swith_to(n):
HGATP = construct_hgatp(...)
3. p2m_handle_vmenter(n):
update VMID if necessary
recalculate HGATP if necessary
(c) update VSATP with n.VSATP if we here from context switch
or with hardware VSATP if it wasn't context switch.
do necessary flushes
And at step (c) we can't base on that if VSATP is zero or not to understand that
it is from context switch as it could that guest at the moment of trap (lets say
some SBI call was requested by guest and Xen just handles it and return back
to guest) also had VSTAP = 0.
So it is needed to distinguish if context switch happened or not to properly
deal
with VSATP (and it was one of the reson to have introduced in this patch
is_ctxt_switch_finished).
... we could find a better way to detect if context switch happened before
entering
VM entry path or not without introduction of its ugly bool variable
is_ctxt_switch_finished as I mentioned above it seems to me it is not enough
just to
check if VSATP is zero or not as guest could had VSATP equal to 0 before trap.
That is why the approach suggested earlier:
For example, assuming CSR
reads aren't overly expensive, it looks to me as if during VM entry
- vsatp only needs writing when vsatp.MODE is zero,
- hgatp only needs writing when vsatp.MODE is zero or when the VMID needs
updating.
as it isn't clear with what should be updated vsatp (vsatp only needs writing
when vsatp.MODE is zero)
with what it was written before we were in a guest or with what ve saved in
vcpu->arch.vsatp during
context switch.
Am I missing something obvious?
Thanks.
~ Oleksii
|
