qemu-riscv
[Top][All Lists]
Advanced

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

Re: [PATCH v2 10/19] target/riscv: remove kvm-stub.c


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH v2 10/19] target/riscv: remove kvm-stub.c
Date: Tue, 12 Sep 2023 13:15:08 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.0

On 12/9/23 12:48, Daniel Henrique Barboza wrote:
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 <dbarboza@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,

Don't get stuck at this; get your series merged, we'll have a look
at that later, this is not important.

Regards,

Phil.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]