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: Daniel Henrique Barboza
Subject: Re: [PATCH v2 10/19] target/riscv: remove kvm-stub.c
Date: Tue, 12 Sep 2023 09:03:32 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0



On 9/12/23 08:15, Philippe Mathieu-Daudé wrote:
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.


Ok, so we'll simplify here and avoid the unneeded stubs for now as we initially 
discussed,
while making sure we're not breaking builds with --enable-debug and clang. 
After this
is merged we can reevaluate the best approach to take.


Thanks,


Daniel


Regards,

Phil.



reply via email to

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