On 9/11/23 09:23, Daniel Henrique Barboza wrote:
On 9/11/23 06:04, Andrew Jones wrote:
On Mon, Sep 11, 2023 at 09:49:06AM +0200, Andrew Jones wrote:
On Wed, Sep 06, 2023 at 12:23:19PM +0200, Philippe Mathieu-Daudé wrote:
On 6/9/23 11:16, Daniel Henrique Barboza wrote:
This file is not needed for some time now. All the stubs implemented in
it (kvm_riscv_reset_vcpu() and kvm_riscv_set_irq()) are wrapped in 'if
kvm_enabled()' blocks that the compiler will rip it out in non-KVM
builds.
We'll also add non-KVM stubs for all functions declared in kvm_riscv.h.
All stubs are implemented as g_asserted_not_reached(), meaning that we
won't support them in non-KVM builds. This is done by other kvm headers
like kvm_arm.h and kvm_ppc.h.
Aren't them also protected by kvm_enabled()? Otherwise shouldn't they?
Yes, I think your earlier suggestion that we always invoke kvm functions
from non-kvm files with a kvm_enabled() guard makes sense.
Signed-off-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
---
target/riscv/kvm-stub.c | 30 ------------------------------
target/riscv/kvm_riscv.h | 31 +++++++++++++++++++++++++++++++
target/riscv/meson.build | 2 +-
3 files changed, 32 insertions(+), 31 deletions(-)
delete mode 100644 target/riscv/kvm-stub.c
diff --git a/target/riscv/kvm_riscv.h b/target/riscv/kvm_riscv.h
index f6501e68e2..c9ecd9a967 100644
--- a/target/riscv/kvm_riscv.h
+++ b/target/riscv/kvm_riscv.h
@@ -19,6 +19,7 @@
#ifndef QEMU_KVM_RISCV_H
#define QEMU_KVM_RISCV_H
+#ifdef CONFIG_KVM
void kvm_riscv_cpu_add_kvm_properties(Object *obj);
At a glance kvm_riscv_cpu_add_kvm_properties() is.
Keep the prototype declared (before #ifdef CONFIG_KVM) is enough for the
compiler to elide it.
Yes, when building without CONFIG_KVM enabled it's actually better to not
have the stubs, since the compiler will catch an unguarded kvm function
call (assuming the kvm function is defined in a file which is only built
with CONFIG_KVM).
Unfortunately we don't have anything to protect developers from forgetting
the kvm_enabled() guard when building a QEMU which supports both TCG and
KVM. We could try to remember to put 'assert(kvm_enabled())' at the start
of each of these types of functions. It looks like mips does that for a
couple functions.
Eh, ignore this suggestion. We don't need asserts, because we have CI. As
long as our CI does a CONFIG_KVM=n build and all KVM functions are in kvm-
only files, then we'll always catch calls of KVM functions which are
missing their kvm_enabled() guards.
So, to sum up, get rid of the 'g_assert_not_reached()' stubs since they should
be cropped by well placed kvm_enabled() calls in the code and, if that's not
the case, a non-KVM build failure will let us know that there's something wrong.
I can live with that. It's less code to deal with in the header as well. Thanks,
I changed my mind after talking with Michael in this thread:
https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg02567.html
There are differences in how gcc and clang (and probably other toolchains)
behave
when choosing to crop code gated with 'if (kvm_enabled && something)'. It is
better to have stubs for all KVM functions to avoid relying on compiler
behavior.
We should keep the stubs in this patch as is. Thanks,
Daniel
Daniel
Thanks,
drew
