* ERROR: modpost: "boot_cpu_hartid" [arch/riscv/kvm/kvm.ko] undefined! @ 2021-11-22 17:14 Adam Borowski 2021-11-22 18:34 ` Sean Christopherson 0 siblings, 1 reply; 5+ messages in thread From: Adam Borowski @ 2021-11-22 17:14 UTC (permalink / raw) To: Anup Patel, kvm-riscv, linux-riscv Hi! With CONFIG_KVM=m and CONFIG_SMP=n, the build fails with: ERROR: modpost: "boot_cpu_hartid" [arch/riscv/kvm/kvm.ko] undefined! An obvious fix would be to change riscv_cpuid_to_hartid_mask() from a static inline function to a real exported symbol, but I wonder: is there a point in allowing such combinations that no one will test? Meow. -- ⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ] ⣾⠁⢠⠒⠀⣿⡁ # beware of races ⢿⡄⠘⠷⠚⠋⠀ all: pillage burn ⠈⠳⣄⠀⠀⠀⠀ `---- _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ERROR: modpost: "boot_cpu_hartid" [arch/riscv/kvm/kvm.ko] undefined! 2021-11-22 17:14 ERROR: modpost: "boot_cpu_hartid" [arch/riscv/kvm/kvm.ko] undefined! Adam Borowski @ 2021-11-22 18:34 ` Sean Christopherson 2021-11-23 5:33 ` Anup Patel 0 siblings, 1 reply; 5+ messages in thread From: Sean Christopherson @ 2021-11-22 18:34 UTC (permalink / raw) To: Adam Borowski; +Cc: Anup Patel, kvm-riscv, linux-riscv On Mon, Nov 22, 2021, Adam Borowski wrote: > Hi! > With CONFIG_KVM=m and CONFIG_SMP=n, the build fails with: > ERROR: modpost: "boot_cpu_hartid" [arch/riscv/kvm/kvm.ko] undefined! > > An obvious fix would be to change riscv_cpuid_to_hartid_mask() from a > static inline function to a real exported symbol Amusingly, the !SMP version is buggy as it assumes the boot/only CPU is in the target mask, which will not always be true, e.g. if a VM has more vCPUs than there are pCPUs in the system, kvm_riscv_vcpu_sbi_ecall() can send in a mask without any CPUs set. Even if that's somewhat of a bogus use case, arguably a common helper shouldn't have different semantics for SMP vs !SMP. > but I wonder: is there a point in allowing such combinations that no one will > test? Eh, even if there is currently no known use case, unless the fix is really nasty, there's no reason to actively prevent a potentially legitimate use case. But it's somewhat of a moot point as the easy fix is to use the SMP version for both cases. I think this would be an appropriate fix? From f6510acd68feb90aa3ec393031cbcde725c52420 Mon Sep 17 00:00:00 2001 From: Sean Christopherson <seanjc@google.com> Date: Mon, 22 Nov 2021 10:01:15 -0800 Subject: [PATCH] RISC-V: Use common riscv_cpuid_to_hartid_mask() for both SMP=y and SMP=n Use what is currently the SMP=y version of riscv_cpuid_to_hartid_mask() for both SMP=y and SMP=n to fix a build failure with KVM=m and SMP=n due to boot_cpu_hartid not being exported. This also fixes a second bug where the SMP=n version assumes the sole CPU in the system is in the incoming mask, which may not hold true in kvm_riscv_vcpu_sbi_ecall() if the KVM guest VM has multiple vCPUs (on a SMP=n system). Reported-by: Adam Borowski <kilobyte@angband.pl> Fixes: 1ef46c231df4 ("RISC-V: Implement new SBI v0.2 extensions") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> --- arch/riscv/include/asm/smp.h | 10 ++-------- arch/riscv/kernel/setup.c | 10 ++++++++++ arch/riscv/kernel/smp.c | 10 ---------- 3 files changed, 12 insertions(+), 18 deletions(-) diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h index a7d2811f3536..62d0e6e61da8 100644 --- a/arch/riscv/include/asm/smp.h +++ b/arch/riscv/include/asm/smp.h @@ -43,7 +43,6 @@ void arch_send_call_function_ipi_mask(struct cpumask *mask); void arch_send_call_function_single_ipi(int cpu); int riscv_hartid_to_cpuid(int hartid); -void riscv_cpuid_to_hartid_mask(const struct cpumask *in, struct cpumask *out); /* Set custom IPI operations */ void riscv_set_ipi_ops(const struct riscv_ipi_ops *ops); @@ -85,13 +84,6 @@ static inline unsigned long cpuid_to_hartid_map(int cpu) return boot_cpu_hartid; } -static inline void riscv_cpuid_to_hartid_mask(const struct cpumask *in, - struct cpumask *out) -{ - cpumask_clear(out); - cpumask_set_cpu(boot_cpu_hartid, out); -} - static inline void riscv_set_ipi_ops(const struct riscv_ipi_ops *ops) { } @@ -102,6 +94,8 @@ static inline void riscv_clear_ipi(void) #endif /* CONFIG_SMP */ +void riscv_cpuid_to_hartid_mask(const struct cpumask *in, struct cpumask *out); + #if defined(CONFIG_HOTPLUG_CPU) && (CONFIG_SMP) bool cpu_has_hotplug(unsigned int cpu); #else diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c index b9620e5f00ba..6c5caf5eb906 100644 --- a/arch/riscv/kernel/setup.c +++ b/arch/riscv/kernel/setup.c @@ -59,6 +59,16 @@ atomic_t hart_lottery __section(".sdata") unsigned long boot_cpu_hartid; static DEFINE_PER_CPU(struct cpu, cpu_devices); +void riscv_cpuid_to_hartid_mask(const struct cpumask *in, struct cpumask *out) +{ + int cpu; + + cpumask_clear(out); + for_each_cpu(cpu, in) + cpumask_set_cpu(cpuid_to_hartid_map(cpu), out); +} +EXPORT_SYMBOL_GPL(riscv_cpuid_to_hartid_mask); + /* * Place kernel memory regions on the resource tree so that * kexec-tools can retrieve them from /proc/iomem. While there diff --git a/arch/riscv/kernel/smp.c b/arch/riscv/kernel/smp.c index 921d9d7df400..d0147294691d 100644 --- a/arch/riscv/kernel/smp.c +++ b/arch/riscv/kernel/smp.c @@ -59,16 +59,6 @@ int riscv_hartid_to_cpuid(int hartid) return -ENOENT; } -void riscv_cpuid_to_hartid_mask(const struct cpumask *in, struct cpumask *out) -{ - int cpu; - - cpumask_clear(out); - for_each_cpu(cpu, in) - cpumask_set_cpu(cpuid_to_hartid_map(cpu), out); -} -EXPORT_SYMBOL_GPL(riscv_cpuid_to_hartid_mask); - bool arch_match_cpu_phys_id(int cpu, u64 phys_id) { return phys_id == cpuid_to_hartid_map(cpu); -- _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: ERROR: modpost: "boot_cpu_hartid" [arch/riscv/kvm/kvm.ko] undefined! 2021-11-22 18:34 ` Sean Christopherson @ 2021-11-23 5:33 ` Anup Patel 2021-11-23 15:07 ` Atish Patra 2021-11-29 21:23 ` Sean Christopherson 0 siblings, 2 replies; 5+ messages in thread From: Anup Patel @ 2021-11-23 5:33 UTC (permalink / raw) To: Sean Christopherson, Adam Borowski, Atish Patra, Palmer Dabbelt Cc: kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org +Atish, +Palmer On 23/11/21, 12:04 AM, "Sean Christopherson" <seanjc@google.com> wrote: On Mon, Nov 22, 2021, Adam Borowski wrote: > Hi! > With CONFIG_KVM=m and CONFIG_SMP=n, the build fails with: > ERROR: modpost: "boot_cpu_hartid" [arch/riscv/kvm/kvm.ko] undefined! > > An obvious fix would be to change riscv_cpuid_to_hartid_mask() from a > static inline function to a real exported symbol Amusingly, the !SMP version is buggy as it assumes the boot/only CPU is in the target mask, which will not always be true, e.g. if a VM has more vCPUs than there are pCPUs in the system, kvm_riscv_vcpu_sbi_ecall() can send in a mask without any CPUs set. Even if that's somewhat of a bogus use case, arguably a common helper shouldn't have different semantics for SMP vs !SMP. > but I wonder: is there a point in allowing such combinations that no one will > test? Eh, even if there is currently no known use case, unless the fix is really nasty, there's no reason to actively prevent a potentially legitimate use case. But it's somewhat of a moot point as the easy fix is to use the SMP version for both cases. I think this would be an appropriate fix? From f6510acd68feb90aa3ec393031cbcde725c52420 Mon Sep 17 00:00:00 2001 From: Sean Christopherson <seanjc@google.com> Date: Mon, 22 Nov 2021 10:01:15 -0800 Subject: [PATCH] RISC-V: Use common riscv_cpuid_to_hartid_mask() for both SMP=y and SMP=n Use what is currently the SMP=y version of riscv_cpuid_to_hartid_mask() for both SMP=y and SMP=n to fix a build failure with KVM=m and SMP=n due to boot_cpu_hartid not being exported. This also fixes a second bug where the SMP=n version assumes the sole CPU in the system is in the incoming mask, which may not hold true in kvm_riscv_vcpu_sbi_ecall() if the KVM guest VM has multiple vCPUs (on a SMP=n system). Reported-by: Adam Borowski <kilobyte@angband.pl> Fixes: 1ef46c231df4 ("RISC-V: Implement new SBI v0.2 extensions") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Yes, this fix looks good for now. Reviewed-by: Anup Patel <anup.patel@wdc.com> As a separate series, we have to totally remove riscv_cpuid_to_hartid_mask() because this function is going to break for sparse HART ids. In fact, we should avoid using "struct cpumask" (which is limited by NR_CPUS) for representing set of HART ids. @Sean, can you re-send this patch to the Linux RISC-V mailing list ? It seems this email did not land correctly for Atish and other folks. Regards, Anup --- arch/riscv/include/asm/smp.h | 10 ++-------- arch/riscv/kernel/setup.c | 10 ++++++++++ arch/riscv/kernel/smp.c | 10 ---------- 3 files changed, 12 insertions(+), 18 deletions(-) diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h index a7d2811f3536..62d0e6e61da8 100644 --- a/arch/riscv/include/asm/smp.h +++ b/arch/riscv/include/asm/smp.h @@ -43,7 +43,6 @@ void arch_send_call_function_ipi_mask(struct cpumask *mask); void arch_send_call_function_single_ipi(int cpu); int riscv_hartid_to_cpuid(int hartid); -void riscv_cpuid_to_hartid_mask(const struct cpumask *in, struct cpumask *out); /* Set custom IPI operations */ void riscv_set_ipi_ops(const struct riscv_ipi_ops *ops); @@ -85,13 +84,6 @@ static inline unsigned long cpuid_to_hartid_map(int cpu) return boot_cpu_hartid; } -static inline void riscv_cpuid_to_hartid_mask(const struct cpumask *in, - struct cpumask *out) -{ - cpumask_clear(out); - cpumask_set_cpu(boot_cpu_hartid, out); -} - static inline void riscv_set_ipi_ops(const struct riscv_ipi_ops *ops) { } @@ -102,6 +94,8 @@ static inline void riscv_clear_ipi(void) #endif /* CONFIG_SMP */ +void riscv_cpuid_to_hartid_mask(const struct cpumask *in, struct cpumask *out); + #if defined(CONFIG_HOTPLUG_CPU) && (CONFIG_SMP) bool cpu_has_hotplug(unsigned int cpu); #else diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c index b9620e5f00ba..6c5caf5eb906 100644 --- a/arch/riscv/kernel/setup.c +++ b/arch/riscv/kernel/setup.c @@ -59,6 +59,16 @@ atomic_t hart_lottery __section(".sdata") unsigned long boot_cpu_hartid; static DEFINE_PER_CPU(struct cpu, cpu_devices); +void riscv_cpuid_to_hartid_mask(const struct cpumask *in, struct cpumask *out) +{ + int cpu; + + cpumask_clear(out); + for_each_cpu(cpu, in) + cpumask_set_cpu(cpuid_to_hartid_map(cpu), out); +} +EXPORT_SYMBOL_GPL(riscv_cpuid_to_hartid_mask); + /* * Place kernel memory regions on the resource tree so that * kexec-tools can retrieve them from /proc/iomem. While there diff --git a/arch/riscv/kernel/smp.c b/arch/riscv/kernel/smp.c index 921d9d7df400..d0147294691d 100644 --- a/arch/riscv/kernel/smp.c +++ b/arch/riscv/kernel/smp.c @@ -59,16 +59,6 @@ int riscv_hartid_to_cpuid(int hartid) return -ENOENT; } -void riscv_cpuid_to_hartid_mask(const struct cpumask *in, struct cpumask *out) -{ - int cpu; - - cpumask_clear(out); - for_each_cpu(cpu, in) - cpumask_set_cpu(cpuid_to_hartid_map(cpu), out); -} -EXPORT_SYMBOL_GPL(riscv_cpuid_to_hartid_mask); - bool arch_match_cpu_phys_id(int cpu, u64 phys_id) { return phys_id == cpuid_to_hartid_map(cpu); -- _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ERROR: modpost: "boot_cpu_hartid" [arch/riscv/kvm/kvm.ko] undefined! 2021-11-23 5:33 ` Anup Patel @ 2021-11-23 15:07 ` Atish Patra 2021-11-29 21:23 ` Sean Christopherson 1 sibling, 0 replies; 5+ messages in thread From: Atish Patra @ 2021-11-23 15:07 UTC (permalink / raw) To: Anup Patel Cc: Sean Christopherson, Adam Borowski, Palmer Dabbelt, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org On Mon, Nov 22, 2021 at 9:33 PM Anup Patel <Anup.Patel@wdc.com> wrote: > > +Atish, +Palmer > > On 23/11/21, 12:04 AM, "Sean Christopherson" <seanjc@google.com> wrote: > > On Mon, Nov 22, 2021, Adam Borowski wrote: > > Hi! > > With CONFIG_KVM=m and CONFIG_SMP=n, the build fails with: > > ERROR: modpost: "boot_cpu_hartid" [arch/riscv/kvm/kvm.ko] undefined! > > > > An obvious fix would be to change riscv_cpuid_to_hartid_mask() from a > > static inline function to a real exported symbol > > Amusingly, the !SMP version is buggy as it assumes the boot/only CPU is in the > target mask, which will not always be true, e.g. if a VM has more vCPUs than there > are pCPUs in the system, kvm_riscv_vcpu_sbi_ecall() can send in a mask without any > CPUs set. Even if that's somewhat of a bogus use case, arguably a common helper > shouldn't have different semantics for SMP vs !SMP. > > > but I wonder: is there a point in allowing such combinations that no one will > > test? > > Eh, even if there is currently no known use case, unless the fix is really nasty, > there's no reason to actively prevent a potentially legitimate use case. But it's > somewhat of a moot point as the easy fix is to use the SMP version for both cases. > > I think this would be an appropriate fix? > > > From f6510acd68feb90aa3ec393031cbcde725c52420 Mon Sep 17 00:00:00 2001 > From: Sean Christopherson <seanjc@google.com> > Date: Mon, 22 Nov 2021 10:01:15 -0800 > Subject: [PATCH] RISC-V: Use common riscv_cpuid_to_hartid_mask() for both > SMP=y and SMP=n > > Use what is currently the SMP=y version of riscv_cpuid_to_hartid_mask() > for both SMP=y and SMP=n to fix a build failure with KVM=m and SMP=n due > to boot_cpu_hartid not being exported. This also fixes a second bug > where the SMP=n version assumes the sole CPU in the system is in the > incoming mask, which may not hold true in kvm_riscv_vcpu_sbi_ecall() if > the KVM guest VM has multiple vCPUs (on a SMP=n system). > > Reported-by: Adam Borowski <kilobyte@angband.pl> > Fixes: 1ef46c231df4 ("RISC-V: Implement new SBI v0.2 extensions") > Cc: stable@vger.kernel.org > Signed-off-by: Sean Christopherson <seanjc@google.com> > > Yes, this fix looks good for now. > > Reviewed-by: Anup Patel <anup.patel@wdc.com> > > As a separate series, we have to totally remove riscv_cpuid_to_hartid_mask() > because this function is going to break for sparse HART ids. In fact, we > should avoid using "struct cpumask" (which is limited by NR_CPUS) for > representing set of HART ids. Yeah. I am working on it. We need to disassociate all the instances of hartid with NR_CPUs to support sparse hartid schemes in the future. > > @Sean, can you re-send this patch to the Linux RISC-V mailing list ? It > seems this email did not land correctly for Atish and other folks. > > Regards, > Anup > > --- > arch/riscv/include/asm/smp.h | 10 ++-------- > arch/riscv/kernel/setup.c | 10 ++++++++++ > arch/riscv/kernel/smp.c | 10 ---------- > 3 files changed, 12 insertions(+), 18 deletions(-) > > diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h > index a7d2811f3536..62d0e6e61da8 100644 > --- a/arch/riscv/include/asm/smp.h > +++ b/arch/riscv/include/asm/smp.h > @@ -43,7 +43,6 @@ void arch_send_call_function_ipi_mask(struct cpumask *mask); > void arch_send_call_function_single_ipi(int cpu); > > int riscv_hartid_to_cpuid(int hartid); > -void riscv_cpuid_to_hartid_mask(const struct cpumask *in, struct cpumask *out); > > /* Set custom IPI operations */ > void riscv_set_ipi_ops(const struct riscv_ipi_ops *ops); > @@ -85,13 +84,6 @@ static inline unsigned long cpuid_to_hartid_map(int cpu) > return boot_cpu_hartid; > } > > -static inline void riscv_cpuid_to_hartid_mask(const struct cpumask *in, > - struct cpumask *out) > -{ > - cpumask_clear(out); > - cpumask_set_cpu(boot_cpu_hartid, out); > -} > - > static inline void riscv_set_ipi_ops(const struct riscv_ipi_ops *ops) > { > } > @@ -102,6 +94,8 @@ static inline void riscv_clear_ipi(void) > > #endif /* CONFIG_SMP */ > > +void riscv_cpuid_to_hartid_mask(const struct cpumask *in, struct cpumask *out); > + > #if defined(CONFIG_HOTPLUG_CPU) && (CONFIG_SMP) > bool cpu_has_hotplug(unsigned int cpu); > #else > diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c > index b9620e5f00ba..6c5caf5eb906 100644 > --- a/arch/riscv/kernel/setup.c > +++ b/arch/riscv/kernel/setup.c > @@ -59,6 +59,16 @@ atomic_t hart_lottery __section(".sdata") > unsigned long boot_cpu_hartid; > static DEFINE_PER_CPU(struct cpu, cpu_devices); > > +void riscv_cpuid_to_hartid_mask(const struct cpumask *in, struct cpumask *out) > +{ > + int cpu; > + > + cpumask_clear(out); > + for_each_cpu(cpu, in) > + cpumask_set_cpu(cpuid_to_hartid_map(cpu), out); > +} > +EXPORT_SYMBOL_GPL(riscv_cpuid_to_hartid_mask); > + > /* > * Place kernel memory regions on the resource tree so that > * kexec-tools can retrieve them from /proc/iomem. While there > diff --git a/arch/riscv/kernel/smp.c b/arch/riscv/kernel/smp.c > index 921d9d7df400..d0147294691d 100644 > --- a/arch/riscv/kernel/smp.c > +++ b/arch/riscv/kernel/smp.c > @@ -59,16 +59,6 @@ int riscv_hartid_to_cpuid(int hartid) > return -ENOENT; > } > > -void riscv_cpuid_to_hartid_mask(const struct cpumask *in, struct cpumask *out) > -{ > - int cpu; > - > - cpumask_clear(out); > - for_each_cpu(cpu, in) > - cpumask_set_cpu(cpuid_to_hartid_map(cpu), out); > -} > -EXPORT_SYMBOL_GPL(riscv_cpuid_to_hartid_mask); > - > bool arch_match_cpu_phys_id(int cpu, u64 phys_id) > { > return phys_id == cpuid_to_hartid_map(cpu); > -- > -- Regards, Atish _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ERROR: modpost: "boot_cpu_hartid" [arch/riscv/kvm/kvm.ko] undefined! 2021-11-23 5:33 ` Anup Patel 2021-11-23 15:07 ` Atish Patra @ 2021-11-29 21:23 ` Sean Christopherson 1 sibling, 0 replies; 5+ messages in thread From: Sean Christopherson @ 2021-11-29 21:23 UTC (permalink / raw) To: Anup Patel Cc: Adam Borowski, Atish Patra, Palmer Dabbelt, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org On Tue, Nov 23, 2021, Anup Patel wrote: > @Sean, can you re-send this patch to the Linux RISC-V mailing list ? It > seems this email did not land correctly for Atish and other folks. Yep, I'll get it posted, sorry for the delay. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-11-29 21:29 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-11-22 17:14 ERROR: modpost: "boot_cpu_hartid" [arch/riscv/kvm/kvm.ko] undefined! Adam Borowski 2021-11-22 18:34 ` Sean Christopherson 2021-11-23 5:33 ` Anup Patel 2021-11-23 15:07 ` Atish Patra 2021-11-29 21:23 ` Sean Christopherson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox