On Wed, Aug 30, 2023 at 10:35:03AM -0300, Daniel Henrique Barboza wrote:
> Commit 6df0b37e2ab breaks a --enable-debug build in a non-KVM
> environment with the following error:
> 
> /usr/bin/ld: libqemu-riscv64-softmmu.fa.p/hw_intc_riscv_aplic.c.o: in 
> function `riscv_kvm_aplic_request':
> ./qemu/build/../hw/intc/riscv_aplic.c:486: undefined reference to 
> `kvm_set_irq'
> collect2: error: ld returned 1 exit status
> 
> This happens because the debug build will poke into the
> 'if (is_kvm_aia(aplic->msimode))' block and fail to find a reference to
> the KVM only function riscv_kvm_aplic_request().
> 
> There are multiple solutions to fix this. We'll go with the same
> solution from the previous patch, i.e. add a kvm_enabled() conditional
> to filter out the block. But there's a catch: riscv_kvm_aplic_request()
> is a local function that would end up being used if the compiler crops
> the block, and this won't work. Quoting Richard Henderson's explanation
> in [1]:
> 
> "(...) the compiler won't eliminate entire unused functions with -O0"
> 
> We'll solve it by moving riscv_kvm_aplic_request() to kvm.c and add its
> declaration in kvm_riscv.h, where all other KVM specific public
> functions are already declared. Other archs handles KVM specific code in
> this manner and we expect to do the same from now on.
> 
> [1] 
> https://lore.kernel.org/qemu-riscv/d2f1ad02-eb03-138f-9d08-db676deee...@linaro.org/
> 
> Signed-off-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
> ---
>  hw/intc/riscv_aplic.c    | 8 ++------
>  target/riscv/kvm.c       | 5 +++++
>  target/riscv/kvm_riscv.h | 1 +
>  3 files changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/intc/riscv_aplic.c b/hw/intc/riscv_aplic.c
> index 592c3ce768..99aae8ccbe 100644
> --- a/hw/intc/riscv_aplic.c
> +++ b/hw/intc/riscv_aplic.c
> @@ -32,6 +32,7 @@
>  #include "target/riscv/cpu.h"
>  #include "sysemu/sysemu.h"
>  #include "sysemu/kvm.h"
> +#include "kvm_riscv.h"
>  #include "migration/vmstate.h"
>  
>  #define APLIC_MAX_IDC                  (1UL << 14)
> @@ -481,11 +482,6 @@ static uint32_t riscv_aplic_idc_claimi(RISCVAPLICState 
> *aplic, uint32_t idc)
>      return topi;
>  }
>  
> -static void riscv_kvm_aplic_request(void *opaque, int irq, int level)
> -{
> -    kvm_set_irq(kvm_state, irq, !!level);
> -}
> -
>  static void riscv_aplic_request(void *opaque, int irq, int level)
>  {
>      bool update = false;
> @@ -840,7 +836,7 @@ static void riscv_aplic_realize(DeviceState *dev, Error 
> **errp)
>       * have IRQ lines delegated by their parent APLIC.
>       */
>      if (!aplic->parent) {
> -        if (is_kvm_aia(aplic->msimode)) {
> +        if (kvm_enabled() && is_kvm_aia(aplic->msimode)) {
>              qdev_init_gpio_in(dev, riscv_kvm_aplic_request, aplic->num_irqs);
>          } else {
>              qdev_init_gpio_in(dev, riscv_aplic_request, aplic->num_irqs);
> diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c
> index faee8536ef..ac28a70723 100644
> --- a/target/riscv/kvm.c
> +++ b/target/riscv/kvm.c
> @@ -46,6 +46,11 @@
>  #include "sysemu/runstate.h"
>  #include "hw/riscv/numa.h"
>  
> +void riscv_kvm_aplic_request(void *opaque, int irq, int level)
> +{
> +    kvm_set_irq(kvm_state, irq, !!level);
> +}
> +
>  static uint64_t kvm_riscv_reg_id(CPURISCVState *env, uint64_t type,
>                                   uint64_t idx)
>  {
> diff --git a/target/riscv/kvm_riscv.h b/target/riscv/kvm_riscv.h
> index 7d4b7c60e2..de8c209ebc 100644
> --- a/target/riscv/kvm_riscv.h
> +++ b/target/riscv/kvm_riscv.h
> @@ -26,5 +26,6 @@ void kvm_riscv_aia_create(MachineState *machine, uint64_t 
> group_shift,
>                            uint64_t aia_irq_num, uint64_t aia_msi_num,
>                            uint64_t aplic_base, uint64_t imsic_base,
>                            uint64_t guest_num);
> +void riscv_kvm_aplic_request(void *opaque, int irq, int level);
>  
>  #endif
> -- 
> 2.41.0
> 
>

I'd also try the always_inline trick with is_kvm_aia(), particularly
because now we're inconsistent with how it's used. In two of the three
places it's called we don't guard it with kvm_enabled().

But, I'm also mostly OK with this, so

Reviewed-by: Andrew Jones <ajo...@ventanamicro.com>

Thanks,
drew

Reply via email to