Re: [PATCH] arch/x86/entry_fred: don't set up KVM IRQs if KVM is disabled

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

 



On 2/15/2024 10:31 PM, Paolo Bonzini wrote:
On 2/16/24 03:10, Xin Li wrote:
On 2/15/2024 11:55 AM, Sean Christopherson wrote:
+Paolo and Stephen

FYI, there's a build failure in -next due to a collision between kvm/next and
tip/x86/fred.  The above makes everything happy.

On Thu, Feb 15, 2024, Max Kellermann wrote:
When KVM is disabled, the POSTED_INTR_* macros do not exist, and the
build fails.

Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code")
Signed-off-by: Max Kellermann <max.kellermann@xxxxxxxxx>
---
  arch/x86/entry/entry_fred.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c
index ac120cbdaaf2..660b7f7f9a79 100644
--- a/arch/x86/entry/entry_fred.c
+++ b/arch/x86/entry/entry_fred.c
@@ -114,9 +114,11 @@ static idtentry_t sysvec_table[NR_SYSTEM_VECTORS] __ro_after_init = {
      SYSVEC(IRQ_WORK_VECTOR,            irq_work),
+#if IS_ENABLED(CONFIG_KVM)
      SYSVEC(POSTED_INTR_VECTOR,        kvm_posted_intr_ipi),
      SYSVEC(POSTED_INTR_WAKEUP_VECTOR,    kvm_posted_intr_wakeup_ipi),
      SYSVEC(POSTED_INTR_NESTED_VECTOR,    kvm_posted_intr_nested_ipi),
+#endif
  };
  static bool fred_setup_done __initdata;
--
2.39.2

We want to minimize #ifdeffery (which is why we didn't add any to
sysvec_table[]), would it be better to simply remove "#if IS_ENABLED(CONFIG_KVM)" around the the POSTED_INTR_* macros from the
Linux-next tree?

BTW, kvm_posted_intr_*() are defined to NULL if !IS_ENABLED(CONFIG_KVM).

It is intentional that KVM-related things are compiled out completely
if !IS_ENABLED(CONFIG_KVM),

In arch/x86/include/asm/irq_vectors.h, most vector definitions are not
under any #ifdeffery, e.g., THERMAL_APIC_VECTOR not under
CONFIG_X86_THERMAL_VECTOR and IRQ_WORK_VECTOR not under CONFIG_IRQ_WORK.

We'd better make all of them consistent, and the question is that should
we add #ifdefs or not.

because then it's also not necessary to have

# define fred_sysvec_kvm_posted_intr_ipi                NULL
# define fred_sysvec_kvm_posted_intr_wakeup_ipi         NULL
# define fred_sysvec_kvm_posted_intr_nested_ipi         NULL

in arch/x86/include/asm/idtentry.h. The full conflict resultion is

diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c
index ac120cbdaaf2..660b7f7f9a79 100644
--- a/arch/x86/entry/entry_fred.c
+++ b/arch/x86/entry/entry_fred.c
@@ -114,9 +114,11 @@ static idtentry_t sysvec_table[NR_SYSTEM_VECTORS] __ro_after_init = {

      SYSVEC(IRQ_WORK_VECTOR,            irq_work),

+#if IS_ENABLED(CONFIG_KVM)
      SYSVEC(POSTED_INTR_VECTOR,        kvm_posted_intr_ipi),
      SYSVEC(POSTED_INTR_WAKEUP_VECTOR,    kvm_posted_intr_wakeup_ipi),
      SYSVEC(POSTED_INTR_NESTED_VECTOR,    kvm_posted_intr_nested_ipi),
+#endif
  };

  static bool fred_setup_done __initdata;
diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentry.h
index 749c7411d2f1..758f6a2838a8 100644
--- a/arch/x86/include/asm/idtentry.h
+++ b/arch/x86/include/asm/idtentry.h
@@ -745,10 +745,6 @@ DECLARE_IDTENTRY_SYSVEC(IRQ_WORK_VECTOR, sysvec_irq_work);  DECLARE_IDTENTRY_SYSVEC(POSTED_INTR_VECTOR, sysvec_kvm_posted_intr_ipi);  DECLARE_IDTENTRY_SYSVEC(POSTED_INTR_WAKEUP_VECTOR, sysvec_kvm_posted_intr_wakeup_ipi);  DECLARE_IDTENTRY_SYSVEC(POSTED_INTR_NESTED_VECTOR, sysvec_kvm_posted_intr_nested_ipi);
-#else
-# define fred_sysvec_kvm_posted_intr_ipi        NULL
-# define fred_sysvec_kvm_posted_intr_wakeup_ipi        NULL
-# define fred_sysvec_kvm_posted_intr_nested_ipi        NULL
  #endif

  #if IS_ENABLED(CONFIG_HYPERV)

and it seems to be a net improvement to me.  The #ifs match in
the .h and .c files, and there are no unnecessary initializers
in the sysvec_table.


I somehow get an impression that the x86 maintainers don't like #ifs in
the .c files, but I could be just wrong.

Thanks!
    Xin





[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux