[PATCH] Fix build without CONFIG_XEN_EMU

[PATCH] Fix build without CONFIG_XEN_EMU

[mrezanin]

From: Miroslav Rezanina <mrezanin@redhat.com>

Upstream commit ddf0fd9ae1 "hw/xen: Support HVM_PARAM_CALLBACK_TYPE_GSI callback"
added kvm_xen_maybe_deassert_callback usage to target/i386/kvm/kvm.c file without
conditional preprocessing check. This breaks any build not using CONFIG_XEN_EMU.

Protect call by conditional preprocessing to allow build without CONFIG_XEN_EMU.

Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>
---
 target/i386/kvm/kvm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index 1aef54f87e..de531842f6 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -4991,6 +4991,7 @@ MemTxAttrs kvm_arch_post_run(CPUState *cpu, struct kvm_run *run)
         kvm_rate_limit_on_bus_lock();
     }
 
+#ifdef CONFIG_XEN_EMU    
     /*
      * If the callback is asserted as a GSI (or PCI INTx) then check if
      * vcpu_info->evtchn_upcall_pending has been cleared, and deassert
@@ -5001,6 +5002,7 @@ MemTxAttrs kvm_arch_post_run(CPUState *cpu, struct kvm_run *run)
     if (x86_cpu->env.xen_callback_asserted) {
         kvm_xen_maybe_deassert_callback(cpu);
     }
+#endif
 
     /* We need to protect the apic state against concurrent accesses from
      * different threads in case the userspace irqchip is used. */
-- 
2.39.1

Re: [PATCH] Fix build without CONFIG_XEN_EMU

[Woodhouse, David via]

[-- Attachment #1.1: Type: text/plain, Size: 645 bytes --]

On Wed, 2023-03-08 at 08:05 -0500, mrezanin@redhat.com wrote:
> From: Miroslav Rezanina <mrezanin@redhat.com>
> 
> Upstream commit ddf0fd9ae1 "hw/xen: Support HVM_PARAM_CALLBACK_TYPE_GSI callback"
> added kvm_xen_maybe_deassert_callback usage to target/i386/kvm/kvm.c file without
> conditional preprocessing check. This breaks any build not using CONFIG_XEN_EMU.
> 
> Protect call by conditional preprocessing to allow build without CONFIG_XEN_EMU.
> 
> Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>

I'll add a build target with that config locally to keep me honest.


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5957 bytes --]

[-- Attachment #2.1: Type: text/plain, Size: 215 bytes --]




Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.



[-- Attachment #2.2: Type: text/html, Size: 228 bytes --]

Re: [PATCH] Fix build without CONFIG_XEN_EMU

[Paolo Bonzini]

On 3/8/23 14:05, mrezanin@redhat.com wrote:
> From: Miroslav Rezanina <mrezanin@redhat.com>
> 
> Upstream commit ddf0fd9ae1 "hw/xen: Support HVM_PARAM_CALLBACK_TYPE_GSI callback"
> added kvm_xen_maybe_deassert_callback usage to target/i386/kvm/kvm.c file without
> conditional preprocessing check. This breaks any build not using CONFIG_XEN_EMU.
> 
> Protect call by conditional preprocessing to allow build without CONFIG_XEN_EMU.
> 
> Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>
> ---
>   target/i386/kvm/kvm.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
> index 1aef54f87e..de531842f6 100644
> --- a/target/i386/kvm/kvm.c
> +++ b/target/i386/kvm/kvm.c
> @@ -4991,6 +4991,7 @@ MemTxAttrs kvm_arch_post_run(CPUState *cpu, struct kvm_run *run)
>           kvm_rate_limit_on_bus_lock();
>       }
>   
> +#ifdef CONFIG_XEN_EMU
>       /*
>        * If the callback is asserted as a GSI (or PCI INTx) then check if
>        * vcpu_info->evtchn_upcall_pending has been cleared, and deassert
> @@ -5001,6 +5002,7 @@ MemTxAttrs kvm_arch_post_run(CPUState *cpu, struct kvm_run *run)
>       if (x86_cpu->env.xen_callback_asserted) {
>           kvm_xen_maybe_deassert_callback(cpu);
>       }
> +#endif
>   
>       /* We need to protect the apic state against concurrent accesses from
>        * different threads in case the userspace irqchip is used. */

Queued, thanks.

Pao