[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |