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

[Andrew Jones]

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.

Thanks,
drew