[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 02/18] xen/riscv: introduce VMID allocation and manegement




On 9/19/25 11:26 PM, Jan Beulich wrote:
On 17.09.2025 23:55, Oleksii Kurochko wrote:
@@ -151,6 +152,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     gstage_mode_detect();
 
+    vmid_init();
Like for the earlier patch, I'm not convinced this is a function good
to call from the top-level start_xen(). The two functions sitting side
by side actually demonstrates the scalability issue pretty well.
In the case of vmid_init(), it could be a good place to call it here since
vmid_init() is expected to be called once when a pCPU is booted. For the boot
CPU, all "setup" functions are called in start_xen(), so vmid_init() could
potentially be called there as well.

For other (non-boot) CPUs, vmid_init() could be called somewhere in the
__cpu_up() code or at the CPU’s entry point.

--- /dev/null
+++ b/xen/arch/riscv/vmid.c
@@ -0,0 +1,193 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include <xen/domain.h>
+#include <xen/init.h>
+#include <xen/sections.h>
+#include <xen/lib.h>
+#include <xen/param.h>
+#include <xen/percpu.h>
+
+#include <asm/atomic.h>
+#include <asm/csr.h>
+#include <asm/flushtlb.h>
+#include <asm/p2m.h>
+
+/* Xen command-line option to enable VMIDs */
+static bool __ro_after_init opt_vmid_use_enabled = true;
+boolean_param("vmid", opt_vmid_use_enabled);
Is there a particular reason to not have the variable be simply opt_vmid,
properly in sync with the command line option?
There is no a specific reason for that, just made it in sync with x86.
opt_vmid could be used instead. I will do s/opt_vmid_use_enabled/opt_vmid.

+void vcpu_vmid_flush_vcpu(struct vcpu *v)
An reason to have two "vcpu" in the name?
The first "vcpu" should be really dropped.

Thanks.

~ Oleksii

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.