[PATCH 0/3] single-binary: compile hw/intc/arm* files once

[PATCH 0/3] single-binary: compile hw/intc/arm* files once

[Pierrick Bouvier]

Move those files to hw/arm, as they depend on arm target code.

Pierrick Bouvier (3):
  hw/arm/arm_gicv3_cpuif_common: move to hw/arm and compile only once
  hw/arm/arm_gicv3_cpuif: move to hw/arm and compile only once
  hw/arm/armv7m_nvic: move to hw/arm and compile only once

 hw/{intc => arm}/arm_gicv3_cpuif.c        |  2 +-
 hw/{intc => arm}/arm_gicv3_cpuif_common.c |  2 +-
 hw/{intc => arm}/armv7m_nvic.c            |  0
 hw/arm/meson.build                        |  3 +
 hw/arm/trace-events                       | 79 +++++++++++++++++++++++
 hw/intc/meson.build                       |  3 -
 hw/intc/trace-events                      | 79 -----------------------
 7 files changed, 84 insertions(+), 84 deletions(-)
 rename hw/{intc => arm}/arm_gicv3_cpuif.c (99%)
 rename hw/{intc => arm}/arm_gicv3_cpuif_common.c (92%)
 rename hw/{intc => arm}/armv7m_nvic.c (100%)

-- 
2.47.2

[PATCH 1/3] hw/arm/arm_gicv3_cpuif_common: move to hw/arm and compile only once

[Pierrick Bouvier]

This file needs definition of ARMCPU, and thus, belongs to hw/arm.

Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
---
 hw/{intc => arm}/arm_gicv3_cpuif_common.c | 2 +-
 hw/arm/meson.build                        | 1 +
 hw/intc/meson.build                       | 1 -
 3 files changed, 2 insertions(+), 2 deletions(-)
 rename hw/{intc => arm}/arm_gicv3_cpuif_common.c (92%)

diff --git a/hw/intc/arm_gicv3_cpuif_common.c b/hw/arm/arm_gicv3_cpuif_common.c
similarity index 92%
rename from hw/intc/arm_gicv3_cpuif_common.c
rename to hw/arm/arm_gicv3_cpuif_common.c
index ff1239f65db..8435ef8cf0d 100644
--- a/hw/intc/arm_gicv3_cpuif_common.c
+++ b/hw/arm/arm_gicv3_cpuif_common.c
@@ -10,7 +10,7 @@
  */
 
 #include "qemu/osdep.h"
-#include "gicv3_internal.h"
+#include "hw/intc/gicv3_internal.h"
 #include "cpu.h"
 
 void gicv3_set_gicv3state(CPUState *cpu, GICv3CPUState *s)
diff --git a/hw/arm/meson.build b/hw/arm/meson.build
index dc68391305f..9f2eea474b4 100644
--- a/hw/arm/meson.build
+++ b/hw/arm/meson.build
@@ -82,6 +82,7 @@ arm_common_ss.add(when: 'CONFIG_VERSATILE', if_true: files('versatilepb.c'))
 arm_common_ss.add(when: 'CONFIG_VEXPRESS', if_true: files('vexpress.c'))
 
 arm_common_ss.add(files('boot.c'))
+arm_common_ss.add(when: 'CONFIG_ARM_GIC', if_true: files('arm_gicv3_cpuif_common.c'))
 
 hw_arch += {'arm': arm_ss}
 hw_common_arch += {'arm': arm_common_ss}
diff --git a/hw/intc/meson.build b/hw/intc/meson.build
index 3137521a4ad..4578c70dc45 100644
--- a/hw/intc/meson.build
+++ b/hw/intc/meson.build
@@ -38,7 +38,6 @@ if config_all_devices.has_key('CONFIG_APIC') or \
 endif
 
 specific_ss.add(when: 'CONFIG_APIC', if_true: files('apic.c', 'apic_common.c'))
-specific_ss.add(when: 'CONFIG_ARM_GIC', if_true: files('arm_gicv3_cpuif_common.c'))
 specific_ss.add(when: 'CONFIG_ARM_GICV3', if_true: files('arm_gicv3_cpuif.c'))
 specific_ss.add(when: 'CONFIG_ARM_GIC_KVM', if_true: files('arm_gic_kvm.c'))
 specific_ss.add(when: ['CONFIG_ARM_GIC_KVM', 'TARGET_AARCH64'], if_true: files('arm_gicv3_kvm.c', 'arm_gicv3_its_kvm.c'))
-- 
2.47.2

[PATCH 2/3] hw/arm/arm_gicv3_cpuif: move to hw/arm and compile only once

[Pierrick Bouvier]

This file needs definition of ARMCPU, and thus, belongs to hw/arm.

Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
---
 hw/{intc => arm}/arm_gicv3_cpuif.c |  2 +-
 hw/arm/meson.build                 |  1 +
 hw/arm/trace-events                | 62 ++++++++++++++++++++++++++++++
 hw/intc/meson.build                |  1 -
 hw/intc/trace-events               | 62 ------------------------------
 5 files changed, 64 insertions(+), 64 deletions(-)
 rename hw/{intc => arm}/arm_gicv3_cpuif.c (99%)

diff --git a/hw/intc/arm_gicv3_cpuif.c b/hw/arm/arm_gicv3_cpuif.c
similarity index 99%
rename from hw/intc/arm_gicv3_cpuif.c
rename to hw/arm/arm_gicv3_cpuif.c
index 4b4cf091570..a3564f2c53d 100644
--- a/hw/intc/arm_gicv3_cpuif.c
+++ b/hw/arm/arm_gicv3_cpuif.c
@@ -17,7 +17,7 @@
 #include "qemu/log.h"
 #include "qemu/main-loop.h"
 #include "trace.h"
-#include "gicv3_internal.h"
+#include "hw/intc/gicv3_internal.h"
 #include "hw/irq.h"
 #include "cpu.h"
 #include "target/arm/cpregs.h"
diff --git a/hw/arm/meson.build b/hw/arm/meson.build
index 9f2eea474b4..25b6bb438a2 100644
--- a/hw/arm/meson.build
+++ b/hw/arm/meson.build
@@ -83,6 +83,7 @@ arm_common_ss.add(when: 'CONFIG_VEXPRESS', if_true: files('vexpress.c'))
 
 arm_common_ss.add(files('boot.c'))
 arm_common_ss.add(when: 'CONFIG_ARM_GIC', if_true: files('arm_gicv3_cpuif_common.c'))
+arm_common_ss.add(when: 'CONFIG_ARM_GICV3', if_true: files('arm_gicv3_cpuif.c'))
 
 hw_arch += {'arm': arm_ss}
 hw_common_arch += {'arm': arm_common_ss}
diff --git a/hw/arm/trace-events b/hw/arm/trace-events
index f3386bd7ae1..250ad116186 100644
--- a/hw/arm/trace-events
+++ b/hw/arm/trace-events
@@ -1,5 +1,67 @@
 # See docs/devel/tracing.rst for syntax documentation.
 
+# arm_gicv3_cpuif.c
+gicv3_icc_pmr_read(uint32_t cpu, uint64_t val) "GICv3 ICC_PMR read cpu 0x%x value 0x%" PRIx64
+gicv3_icc_pmr_write(uint32_t cpu, uint64_t val) "GICv3 ICC_PMR write cpu 0x%x value 0x%" PRIx64
+gicv3_icc_bpr_read(int grp, uint32_t cpu, uint64_t val) "GICv3 ICC_BPR%d read cpu 0x%x value 0x%" PRIx64
+gicv3_icc_bpr_write(int grp, uint32_t cpu, uint64_t val) "GICv3 ICC_BPR%d write cpu 0x%x value 0x%" PRIx64
+gicv3_icc_ap_read(int grp, int regno, uint32_t cpu, uint64_t val) "GICv3 ICC_AP%dR%d read cpu 0x%x value 0x%" PRIx64
+gicv3_icc_ap_write(int grp, int regno, uint32_t cpu, uint64_t val) "GICv3 ICC_AP%dR%d write cpu 0x%x value 0x%" PRIx64
+gicv3_icc_igrpen_read(int grp, uint32_t cpu, uint64_t val) "GICv3 ICC_IGRPEN%d read cpu 0x%x value 0x%" PRIx64
+gicv3_icc_igrpen_write(int grp, uint32_t cpu, uint64_t val) "GICv3 ICC_IGRPEN%d write cpu 0x%x value 0x%" PRIx64
+gicv3_icc_igrpen1_el3_read(uint32_t cpu, uint64_t val) "GICv3 ICC_IGRPEN1_EL3 read cpu 0x%x value 0x%" PRIx64
+gicv3_icc_igrpen1_el3_write(uint32_t cpu, uint64_t val) "GICv3 ICC_IGRPEN1_EL3 write cpu 0x%x value 0x%" PRIx64
+gicv3_icc_ctlr_read(uint32_t cpu, uint64_t val) "GICv3 ICC_CTLR read cpu 0x%x value 0x%" PRIx64
+gicv3_icc_ctlr_write(uint32_t cpu, uint64_t val) "GICv3 ICC_CTLR write cpu 0x%x value 0x%" PRIx64
+gicv3_icc_ctlr_el3_read(uint32_t cpu, uint64_t val) "GICv3 ICC_CTLR_EL3 read cpu 0x%x value 0x%" PRIx64
+gicv3_icc_ctlr_el3_write(uint32_t cpu, uint64_t val) "GICv3 ICC_CTLR_EL3 write cpu 0x%x value 0x%" PRIx64
+gicv3_cpuif_update(uint32_t cpuid, int irq, int grp, int prio) "GICv3 CPU i/f 0x%x HPPI update: irq %d group %d prio %d"
+gicv3_cpuif_set_irqs(uint32_t cpuid, int fiqlevel, int irqlevel) "GICv3 CPU i/f 0x%x HPPI update: setting FIQ %d IRQ %d"
+gicv3_icc_generate_sgi(uint32_t cpuid, int irq, int irm, uint32_t aff, uint32_t targetlist) "GICv3 CPU i/f 0x%x generating SGI %d IRM %d target affinity 0x%xxx targetlist 0x%x"
+gicv3_icc_iar0_read(uint32_t cpu, uint64_t val) "GICv3 ICC_IAR0 read cpu 0x%x value 0x%" PRIx64
+gicv3_icc_iar1_read(uint32_t cpu, uint64_t val) "GICv3 ICC_IAR1 read cpu 0x%x value 0x%" PRIx64
+gicv3_icc_nmiar1_read(uint32_t cpu, uint64_t val) "GICv3 ICC_NMIAR1 read cpu 0x%x value 0x%" PRIx64
+gicv3_icc_eoir_write(int grp, uint32_t cpu, uint64_t val) "GICv3 ICC_EOIR%d write cpu 0x%x value 0x%" PRIx64
+gicv3_icc_hppir0_read(uint32_t cpu, uint64_t val) "GICv3 ICC_HPPIR0 read cpu 0x%x value 0x%" PRIx64
+gicv3_icc_hppir1_read(uint32_t cpu, uint64_t val) "GICv3 ICC_HPPIR1 read cpu 0x%x value 0x%" PRIx64
+gicv3_icc_dir_write(uint32_t cpu, uint64_t val) "GICv3 ICC_DIR write cpu 0x%x value 0x%" PRIx64
+gicv3_icc_rpr_read(uint32_t cpu, uint64_t val) "GICv3 ICC_RPR read cpu 0x%x value 0x%" PRIx64
+gicv3_ich_ap_read(int grp, int regno, uint32_t cpu, uint64_t val) "GICv3 ICH_AP%dR%d read cpu 0x%x value 0x%" PRIx64
+gicv3_ich_ap_write(int grp, int regno, uint32_t cpu, uint64_t val) "GICv3 ICH_AP%dR%d write cpu 0x%x value 0x%" PRIx64
+gicv3_ich_hcr_read(uint32_t cpu, uint64_t val) "GICv3 ICH_HCR_EL2 read cpu 0x%x value 0x%" PRIx64
+gicv3_ich_hcr_write(uint32_t cpu, uint64_t val) "GICv3 ICH_HCR_EL2 write cpu 0x%x value 0x%" PRIx64
+gicv3_ich_vmcr_read(uint32_t cpu, uint64_t val) "GICv3 ICH_VMCR_EL2 read cpu 0x%x value 0x%" PRIx64
+gicv3_ich_vmcr_write(uint32_t cpu, uint64_t val) "GICv3 ICH_VMCR_EL2 write cpu 0x%x value 0x%" PRIx64
+gicv3_ich_lr_read(int regno, uint32_t cpu, uint64_t val) "GICv3 ICH_LR%d_EL2 read cpu 0x%x value 0x%" PRIx64
+gicv3_ich_lr32_read(int regno, uint32_t cpu, uint32_t val) "GICv3 ICH_LR%d read cpu 0x%x value 0x%" PRIx32
+gicv3_ich_lrc_read(int regno, uint32_t cpu, uint32_t val) "GICv3 ICH_LRC%d read cpu 0x%x value 0x%" PRIx32
+gicv3_ich_lr_write(int regno, uint32_t cpu, uint64_t val) "GICv3 ICH_LR%d_EL2 write cpu 0x%x value 0x%" PRIx64
+gicv3_ich_lr32_write(int regno, uint32_t cpu, uint32_t val) "GICv3 ICH_LR%d write cpu 0x%x value 0x%" PRIx32
+gicv3_ich_lrc_write(int regno, uint32_t cpu, uint32_t val) "GICv3 ICH_LRC%d write cpu 0x%x value 0x%" PRIx32
+gicv3_ich_vtr_read(uint32_t cpu, uint64_t val) "GICv3 ICH_VTR read cpu 0x%x value 0x%" PRIx64
+gicv3_ich_misr_read(uint32_t cpu, uint64_t val) "GICv3 ICH_MISR read cpu 0x%x value 0x%" PRIx64
+gicv3_ich_eisr_read(uint32_t cpu, uint64_t val) "GICv3 ICH_EISR read cpu 0x%x value 0x%" PRIx64
+gicv3_ich_elrsr_read(uint32_t cpu, uint64_t val) "GICv3 ICH_ELRSR read cpu 0x%x value 0x%" PRIx64
+gicv3_icv_ap_read(int grp, int regno, uint32_t cpu, uint64_t val) "GICv3 ICV_AP%dR%d read cpu 0x%x value 0x%" PRIx64
+gicv3_icv_ap_write(int grp, int regno, uint32_t cpu, uint64_t val) "GICv3 ICV_AP%dR%d write cpu 0x%x value 0x%" PRIx64
+gicv3_icv_bpr_read(int grp, uint32_t cpu, uint64_t val) "GICv3 ICV_BPR%d read cpu 0x%x value 0x%" PRIx64
+gicv3_icv_bpr_write(int grp, uint32_t cpu, uint64_t val) "GICv3 ICV_BPR%d write cpu 0x%x value 0x%" PRIx64
+gicv3_icv_pmr_read(uint32_t cpu, uint64_t val) "GICv3 ICV_PMR read cpu 0x%x value 0x%" PRIx64
+gicv3_icv_pmr_write(uint32_t cpu, uint64_t val) "GICv3 ICV_PMR write cpu 0x%x value 0x%" PRIx64
+gicv3_icv_igrpen_read(int grp, uint32_t cpu, uint64_t val) "GICv3 ICV_IGRPEN%d read cpu 0x%x value 0x%" PRIx64
+gicv3_icv_igrpen_write(int grp, uint32_t cpu, uint64_t val) "GICv3 ICV_IGRPEN%d write cpu 0x%x value 0x%" PRIx64
+gicv3_icv_ctlr_read(uint32_t cpu, uint64_t val) "GICv3 ICV_CTLR read cpu 0x%x value 0x%" PRIx64
+gicv3_icv_ctlr_write(uint32_t cpu, uint64_t val) "GICv3 ICV_CTLR write cpu 0x%x value 0x%" PRIx64
+gicv3_icv_rpr_read(uint32_t cpu, uint64_t val) "GICv3 ICV_RPR read cpu 0x%x value 0x%" PRIx64
+gicv3_icv_hppir_read(int grp, uint32_t cpu, uint64_t val) "GICv3 ICV_HPPIR%d read cpu 0x%x value 0x%" PRIx64
+gicv3_icv_dir_write(uint32_t cpu, uint64_t val) "GICv3 ICV_DIR write cpu 0x%x value 0x%" PRIx64
+gicv3_icv_iar_read(int grp, uint32_t cpu, uint64_t val) "GICv3 ICV_IAR%d read cpu 0x%x value 0x%" PRIx64
+gicv3_icv_nmiar1_read(uint32_t cpu, uint64_t val) "GICv3 ICV_NMIAR1 read cpu 0x%x value 0x%" PRIx64
+gicv3_icv_eoir_write(int grp, uint32_t cpu, uint64_t val) "GICv3 ICV_EOIR%d write cpu 0x%x value 0x%" PRIx64
+gicv3_cpuif_virt_update(uint32_t cpuid, int idx, int hppvlpi, int grp, int prio) "GICv3 CPU i/f 0x%x virt HPPI update LR index %d HPPVLPI %d grp %d prio %d"
+gicv3_cpuif_virt_set_irqs(uint32_t cpuid, int fiqlevel, int irqlevel) "GICv3 CPU i/f 0x%x virt HPPI update: setting FIQ %d IRQ %d"
+gicv3_cpuif_virt_set_maint_irq(uint32_t cpuid, int maintlevel) "GICv3 CPU i/f 0x%x virt HPPI update: setting maintenance-irq %d"
+
 # omap1.c
 omap1_pwl_clocking_scheme(const char *scheme) "omap1 CLKM: clocking scheme set to %s"
 omap1_pwl_backlight(int output) "omap1 PWL: backlight now at %d/256"
diff --git a/hw/intc/meson.build b/hw/intc/meson.build
index 4578c70dc45..22814893cbe 100644
--- a/hw/intc/meson.build
+++ b/hw/intc/meson.build
@@ -38,7 +38,6 @@ if config_all_devices.has_key('CONFIG_APIC') or \
 endif
 
 specific_ss.add(when: 'CONFIG_APIC', if_true: files('apic.c', 'apic_common.c'))
-specific_ss.add(when: 'CONFIG_ARM_GICV3', if_true: files('arm_gicv3_cpuif.c'))
 specific_ss.add(when: 'CONFIG_ARM_GIC_KVM', if_true: files('arm_gic_kvm.c'))
 specific_ss.add(when: ['CONFIG_ARM_GIC_KVM', 'TARGET_AARCH64'], if_true: files('arm_gicv3_kvm.c', 'arm_gicv3_its_kvm.c'))
 specific_ss.add(when: 'CONFIG_ARM_V7M', if_true: files('armv7m_nvic.c'))
diff --git a/hw/intc/trace-events b/hw/intc/trace-events
index 018c609ca5e..4d6c886b794 100644
--- a/hw/intc/trace-events
+++ b/hw/intc/trace-events
@@ -110,68 +110,6 @@ gic_dist_write(int addr, unsigned int size, uint32_t val) "dist write at 0x%08x
 gic_lr_entry(int cpu, int entry, uint32_t val) "cpu %d: new lr entry %d: 0x%08" PRIx32
 gic_update_maintenance_irq(int cpu, int val) "cpu %d: maintenance = %d"
 
-# arm_gicv3_cpuif.c
-gicv3_icc_pmr_read(uint32_t cpu, uint64_t val) "GICv3 ICC_PMR read cpu 0x%x value 0x%" PRIx64
-gicv3_icc_pmr_write(uint32_t cpu, uint64_t val) "GICv3 ICC_PMR write cpu 0x%x value 0x%" PRIx64
-gicv3_icc_bpr_read(int grp, uint32_t cpu, uint64_t val) "GICv3 ICC_BPR%d read cpu 0x%x value 0x%" PRIx64
-gicv3_icc_bpr_write(int grp, uint32_t cpu, uint64_t val) "GICv3 ICC_BPR%d write cpu 0x%x value 0x%" PRIx64
-gicv3_icc_ap_read(int grp, int regno, uint32_t cpu, uint64_t val) "GICv3 ICC_AP%dR%d read cpu 0x%x value 0x%" PRIx64
-gicv3_icc_ap_write(int grp, int regno, uint32_t cpu, uint64_t val) "GICv3 ICC_AP%dR%d write cpu 0x%x value 0x%" PRIx64
-gicv3_icc_igrpen_read(int grp, uint32_t cpu, uint64_t val) "GICv3 ICC_IGRPEN%d read cpu 0x%x value 0x%" PRIx64
-gicv3_icc_igrpen_write(int grp, uint32_t cpu, uint64_t val) "GICv3 ICC_IGRPEN%d write cpu 0x%x value 0x%" PRIx64
-gicv3_icc_igrpen1_el3_read(uint32_t cpu, uint64_t val) "GICv3 ICC_IGRPEN1_EL3 read cpu 0x%x value 0x%" PRIx64
-gicv3_icc_igrpen1_el3_write(uint32_t cpu, uint64_t val) "GICv3 ICC_IGRPEN1_EL3 write cpu 0x%x value 0x%" PRIx64
-gicv3_icc_ctlr_read(uint32_t cpu, uint64_t val) "GICv3 ICC_CTLR read cpu 0x%x value 0x%" PRIx64
-gicv3_icc_ctlr_write(uint32_t cpu, uint64_t val) "GICv3 ICC_CTLR write cpu 0x%x value 0x%" PRIx64
-gicv3_icc_ctlr_el3_read(uint32_t cpu, uint64_t val) "GICv3 ICC_CTLR_EL3 read cpu 0x%x value 0x%" PRIx64
-gicv3_icc_ctlr_el3_write(uint32_t cpu, uint64_t val) "GICv3 ICC_CTLR_EL3 write cpu 0x%x value 0x%" PRIx64
-gicv3_cpuif_update(uint32_t cpuid, int irq, int grp, int prio) "GICv3 CPU i/f 0x%x HPPI update: irq %d group %d prio %d"
-gicv3_cpuif_set_irqs(uint32_t cpuid, int fiqlevel, int irqlevel) "GICv3 CPU i/f 0x%x HPPI update: setting FIQ %d IRQ %d"
-gicv3_icc_generate_sgi(uint32_t cpuid, int irq, int irm, uint32_t aff, uint32_t targetlist) "GICv3 CPU i/f 0x%x generating SGI %d IRM %d target affinity 0x%xxx targetlist 0x%x"
-gicv3_icc_iar0_read(uint32_t cpu, uint64_t val) "GICv3 ICC_IAR0 read cpu 0x%x value 0x%" PRIx64
-gicv3_icc_iar1_read(uint32_t cpu, uint64_t val) "GICv3 ICC_IAR1 read cpu 0x%x value 0x%" PRIx64
-gicv3_icc_nmiar1_read(uint32_t cpu, uint64_t val) "GICv3 ICC_NMIAR1 read cpu 0x%x value 0x%" PRIx64
-gicv3_icc_eoir_write(int grp, uint32_t cpu, uint64_t val) "GICv3 ICC_EOIR%d write cpu 0x%x value 0x%" PRIx64
-gicv3_icc_hppir0_read(uint32_t cpu, uint64_t val) "GICv3 ICC_HPPIR0 read cpu 0x%x value 0x%" PRIx64
-gicv3_icc_hppir1_read(uint32_t cpu, uint64_t val) "GICv3 ICC_HPPIR1 read cpu 0x%x value 0x%" PRIx64
-gicv3_icc_dir_write(uint32_t cpu, uint64_t val) "GICv3 ICC_DIR write cpu 0x%x value 0x%" PRIx64
-gicv3_icc_rpr_read(uint32_t cpu, uint64_t val) "GICv3 ICC_RPR read cpu 0x%x value 0x%" PRIx64
-gicv3_ich_ap_read(int grp, int regno, uint32_t cpu, uint64_t val) "GICv3 ICH_AP%dR%d read cpu 0x%x value 0x%" PRIx64
-gicv3_ich_ap_write(int grp, int regno, uint32_t cpu, uint64_t val) "GICv3 ICH_AP%dR%d write cpu 0x%x value 0x%" PRIx64
-gicv3_ich_hcr_read(uint32_t cpu, uint64_t val) "GICv3 ICH_HCR_EL2 read cpu 0x%x value 0x%" PRIx64
-gicv3_ich_hcr_write(uint32_t cpu, uint64_t val) "GICv3 ICH_HCR_EL2 write cpu 0x%x value 0x%" PRIx64
-gicv3_ich_vmcr_read(uint32_t cpu, uint64_t val) "GICv3 ICH_VMCR_EL2 read cpu 0x%x value 0x%" PRIx64
-gicv3_ich_vmcr_write(uint32_t cpu, uint64_t val) "GICv3 ICH_VMCR_EL2 write cpu 0x%x value 0x%" PRIx64
-gicv3_ich_lr_read(int regno, uint32_t cpu, uint64_t val) "GICv3 ICH_LR%d_EL2 read cpu 0x%x value 0x%" PRIx64
-gicv3_ich_lr32_read(int regno, uint32_t cpu, uint32_t val) "GICv3 ICH_LR%d read cpu 0x%x value 0x%" PRIx32
-gicv3_ich_lrc_read(int regno, uint32_t cpu, uint32_t val) "GICv3 ICH_LRC%d read cpu 0x%x value 0x%" PRIx32
-gicv3_ich_lr_write(int regno, uint32_t cpu, uint64_t val) "GICv3 ICH_LR%d_EL2 write cpu 0x%x value 0x%" PRIx64
-gicv3_ich_lr32_write(int regno, uint32_t cpu, uint32_t val) "GICv3 ICH_LR%d write cpu 0x%x value 0x%" PRIx32
-gicv3_ich_lrc_write(int regno, uint32_t cpu, uint32_t val) "GICv3 ICH_LRC%d write cpu 0x%x value 0x%" PRIx32
-gicv3_ich_vtr_read(uint32_t cpu, uint64_t val) "GICv3 ICH_VTR read cpu 0x%x value 0x%" PRIx64
-gicv3_ich_misr_read(uint32_t cpu, uint64_t val) "GICv3 ICH_MISR read cpu 0x%x value 0x%" PRIx64
-gicv3_ich_eisr_read(uint32_t cpu, uint64_t val) "GICv3 ICH_EISR read cpu 0x%x value 0x%" PRIx64
-gicv3_ich_elrsr_read(uint32_t cpu, uint64_t val) "GICv3 ICH_ELRSR read cpu 0x%x value 0x%" PRIx64
-gicv3_icv_ap_read(int grp, int regno, uint32_t cpu, uint64_t val) "GICv3 ICV_AP%dR%d read cpu 0x%x value 0x%" PRIx64
-gicv3_icv_ap_write(int grp, int regno, uint32_t cpu, uint64_t val) "GICv3 ICV_AP%dR%d write cpu 0x%x value 0x%" PRIx64
-gicv3_icv_bpr_read(int grp, uint32_t cpu, uint64_t val) "GICv3 ICV_BPR%d read cpu 0x%x value 0x%" PRIx64
-gicv3_icv_bpr_write(int grp, uint32_t cpu, uint64_t val) "GICv3 ICV_BPR%d write cpu 0x%x value 0x%" PRIx64
-gicv3_icv_pmr_read(uint32_t cpu, uint64_t val) "GICv3 ICV_PMR read cpu 0x%x value 0x%" PRIx64
-gicv3_icv_pmr_write(uint32_t cpu, uint64_t val) "GICv3 ICV_PMR write cpu 0x%x value 0x%" PRIx64
-gicv3_icv_igrpen_read(int grp, uint32_t cpu, uint64_t val) "GICv3 ICV_IGRPEN%d read cpu 0x%x value 0x%" PRIx64
-gicv3_icv_igrpen_write(int grp, uint32_t cpu, uint64_t val) "GICv3 ICV_IGRPEN%d write cpu 0x%x value 0x%" PRIx64
-gicv3_icv_ctlr_read(uint32_t cpu, uint64_t val) "GICv3 ICV_CTLR read cpu 0x%x value 0x%" PRIx64
-gicv3_icv_ctlr_write(uint32_t cpu, uint64_t val) "GICv3 ICV_CTLR write cpu 0x%x value 0x%" PRIx64
-gicv3_icv_rpr_read(uint32_t cpu, uint64_t val) "GICv3 ICV_RPR read cpu 0x%x value 0x%" PRIx64
-gicv3_icv_hppir_read(int grp, uint32_t cpu, uint64_t val) "GICv3 ICV_HPPIR%d read cpu 0x%x value 0x%" PRIx64
-gicv3_icv_dir_write(uint32_t cpu, uint64_t val) "GICv3 ICV_DIR write cpu 0x%x value 0x%" PRIx64
-gicv3_icv_iar_read(int grp, uint32_t cpu, uint64_t val) "GICv3 ICV_IAR%d read cpu 0x%x value 0x%" PRIx64
-gicv3_icv_nmiar1_read(uint32_t cpu, uint64_t val) "GICv3 ICV_NMIAR1 read cpu 0x%x value 0x%" PRIx64
-gicv3_icv_eoir_write(int grp, uint32_t cpu, uint64_t val) "GICv3 ICV_EOIR%d write cpu 0x%x value 0x%" PRIx64
-gicv3_cpuif_virt_update(uint32_t cpuid, int idx, int hppvlpi, int grp, int prio) "GICv3 CPU i/f 0x%x virt HPPI update LR index %d HPPVLPI %d grp %d prio %d"
-gicv3_cpuif_virt_set_irqs(uint32_t cpuid, int fiqlevel, int irqlevel) "GICv3 CPU i/f 0x%x virt HPPI update: setting FIQ %d IRQ %d"
-gicv3_cpuif_virt_set_maint_irq(uint32_t cpuid, int maintlevel) "GICv3 CPU i/f 0x%x virt HPPI update: setting maintenance-irq %d"
-
 # arm_gicv3_dist.c
 gicv3_dist_read(uint64_t offset, uint64_t data, unsigned size, bool secure) "GICv3 distributor read: offset 0x%" PRIx64 " data 0x%" PRIx64 " size %u secure %d"
 gicv3_dist_badread(uint64_t offset, unsigned size, bool secure) "GICv3 distributor read: offset 0x%" PRIx64 " size %u secure %d: error"
-- 
2.47.2

[PATCH 3/3] hw/arm/armv7m_nvic: move to hw/arm and compile only once

[Pierrick Bouvier]

This file needs definition of ARMCPU, and thus, belongs to hw/arm.

Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
---
 hw/{intc => arm}/armv7m_nvic.c |  0
 hw/arm/meson.build             |  1 +
 hw/arm/trace-events            | 17 +++++++++++++++++
 hw/intc/meson.build            |  1 -
 hw/intc/trace-events           | 17 -----------------
 5 files changed, 18 insertions(+), 18 deletions(-)
 rename hw/{intc => arm}/armv7m_nvic.c (100%)

diff --git a/hw/intc/armv7m_nvic.c b/hw/arm/armv7m_nvic.c
similarity index 100%
rename from hw/intc/armv7m_nvic.c
rename to hw/arm/armv7m_nvic.c
diff --git a/hw/arm/meson.build b/hw/arm/meson.build
index 25b6bb438a2..68dbdd3e913 100644
--- a/hw/arm/meson.build
+++ b/hw/arm/meson.build
@@ -84,6 +84,7 @@ arm_common_ss.add(when: 'CONFIG_VEXPRESS', if_true: files('vexpress.c'))
 arm_common_ss.add(files('boot.c'))
 arm_common_ss.add(when: 'CONFIG_ARM_GIC', if_true: files('arm_gicv3_cpuif_common.c'))
 arm_common_ss.add(when: 'CONFIG_ARM_GICV3', if_true: files('arm_gicv3_cpuif.c'))
+arm_common_ss.add(when: 'CONFIG_ARM_V7M', if_true: files('armv7m_nvic.c'))
 
 hw_arch += {'arm': arm_ss}
 hw_common_arch += {'arm': arm_common_ss}
diff --git a/hw/arm/trace-events b/hw/arm/trace-events
index 250ad116186..e25fa32668c 100644
--- a/hw/arm/trace-events
+++ b/hw/arm/trace-events
@@ -62,6 +62,23 @@ gicv3_cpuif_virt_update(uint32_t cpuid, int idx, int hppvlpi, int grp, int prio)
 gicv3_cpuif_virt_set_irqs(uint32_t cpuid, int fiqlevel, int irqlevel) "GICv3 CPU i/f 0x%x virt HPPI update: setting FIQ %d IRQ %d"
 gicv3_cpuif_virt_set_maint_irq(uint32_t cpuid, int maintlevel) "GICv3 CPU i/f 0x%x virt HPPI update: setting maintenance-irq %d"
 
+# armv7m_nvic.c
+nvic_recompute_state(int vectpending, int vectpending_prio, int exception_prio) "NVIC state recomputed: vectpending %d vectpending_prio %d exception_prio %d"
+nvic_recompute_state_secure(int vectpending, bool vectpending_is_s_banked, int vectpending_prio, int exception_prio) "NVIC state recomputed: vectpending %d is_s_banked %d vectpending_prio %d exception_prio %d"
+nvic_set_prio(int irq, bool secure, uint8_t prio) "NVIC set irq %d secure-bank %d priority %d"
+nvic_irq_update(int vectpending, int pendprio, int exception_prio, int level) "NVIC vectpending %d pending prio %d exception_prio %d: setting irq line to %d"
+nvic_escalate_prio(int irq, int irqprio, int runprio) "NVIC escalating irq %d to HardFault: insufficient priority %d >= %d"
+nvic_escalate_disabled(int irq) "NVIC escalating irq %d to HardFault: disabled"
+nvic_set_pending(int irq, bool secure, bool targets_secure, bool derived, int en, int prio) "NVIC set pending irq %d secure-bank %d targets_secure %d derived %d (enabled: %d priority %d)"
+nvic_clear_pending(int irq, bool secure, int en, int prio) "NVIC clear pending irq %d secure-bank %d (enabled: %d priority %d)"
+nvic_acknowledge_irq(int irq, int prio) "NVIC acknowledge IRQ: %d now active (prio %d)"
+nvic_get_pending_irq_info(int irq, bool secure) "NVIC next IRQ %d: targets_secure: %d"
+nvic_complete_irq(int irq, bool secure) "NVIC complete IRQ %d (secure %d)"
+nvic_set_irq_level(int irq, int level) "NVIC external irq %d level set to %d"
+nvic_set_nmi_level(int level) "NVIC external NMI level set to %d"
+nvic_sysreg_read(uint64_t addr, uint32_t value, unsigned size) "NVIC sysreg read addr 0x%" PRIx64 " data 0x%" PRIx32 " size %u"
+nvic_sysreg_write(uint64_t addr, uint32_t value, unsigned size) "NVIC sysreg write addr 0x%" PRIx64 " data 0x%" PRIx32 " size %u"
+
 # omap1.c
 omap1_pwl_clocking_scheme(const char *scheme) "omap1 CLKM: clocking scheme set to %s"
 omap1_pwl_backlight(int output) "omap1 PWL: backlight now at %d/256"
diff --git a/hw/intc/meson.build b/hw/intc/meson.build
index 22814893cbe..dc857833dcb 100644
--- a/hw/intc/meson.build
+++ b/hw/intc/meson.build
@@ -40,7 +40,6 @@ endif
 specific_ss.add(when: 'CONFIG_APIC', if_true: files('apic.c', 'apic_common.c'))
 specific_ss.add(when: 'CONFIG_ARM_GIC_KVM', if_true: files('arm_gic_kvm.c'))
 specific_ss.add(when: ['CONFIG_ARM_GIC_KVM', 'TARGET_AARCH64'], if_true: files('arm_gicv3_kvm.c', 'arm_gicv3_its_kvm.c'))
-specific_ss.add(when: 'CONFIG_ARM_V7M', if_true: files('armv7m_nvic.c'))
 specific_ss.add(when: 'CONFIG_GRLIB', if_true: files('grlib_irqmp.c'))
 specific_ss.add(when: 'CONFIG_IOAPIC', if_true: files('ioapic.c'))
 specific_ss.add(when: 'CONFIG_LOONGSON_LIOINTC', if_true: files('loongson_liointc.c'))
diff --git a/hw/intc/trace-events b/hw/intc/trace-events
index 4d6c886b794..aa9d65fdc25 100644
--- a/hw/intc/trace-events
+++ b/hw/intc/trace-events
@@ -165,23 +165,6 @@ gicv3_its_vte_read(uint32_t vpeid, int valid, uint32_t vptsize, uint64_t vptaddr
 gicv3_its_vte_read_fault(uint32_t vpeid) "GICv3 ITS: vPE Table read for vPEID 0x%x: faulted"
 gicv3_its_vte_write(uint32_t vpeid, int valid, uint32_t vptsize, uint64_t vptaddr, uint32_t rdbase) "GICv3 ITS: vPE Table write for vPEID 0x%x: valid %d VPTsize 0x%x VPTaddr 0x%" PRIx64 " RDbase 0x%x"
 
-# armv7m_nvic.c
-nvic_recompute_state(int vectpending, int vectpending_prio, int exception_prio) "NVIC state recomputed: vectpending %d vectpending_prio %d exception_prio %d"
-nvic_recompute_state_secure(int vectpending, bool vectpending_is_s_banked, int vectpending_prio, int exception_prio) "NVIC state recomputed: vectpending %d is_s_banked %d vectpending_prio %d exception_prio %d"
-nvic_set_prio(int irq, bool secure, uint8_t prio) "NVIC set irq %d secure-bank %d priority %d"
-nvic_irq_update(int vectpending, int pendprio, int exception_prio, int level) "NVIC vectpending %d pending prio %d exception_prio %d: setting irq line to %d"
-nvic_escalate_prio(int irq, int irqprio, int runprio) "NVIC escalating irq %d to HardFault: insufficient priority %d >= %d"
-nvic_escalate_disabled(int irq) "NVIC escalating irq %d to HardFault: disabled"
-nvic_set_pending(int irq, bool secure, bool targets_secure, bool derived, int en, int prio) "NVIC set pending irq %d secure-bank %d targets_secure %d derived %d (enabled: %d priority %d)"
-nvic_clear_pending(int irq, bool secure, int en, int prio) "NVIC clear pending irq %d secure-bank %d (enabled: %d priority %d)"
-nvic_acknowledge_irq(int irq, int prio) "NVIC acknowledge IRQ: %d now active (prio %d)"
-nvic_get_pending_irq_info(int irq, bool secure) "NVIC next IRQ %d: targets_secure: %d"
-nvic_complete_irq(int irq, bool secure) "NVIC complete IRQ %d (secure %d)"
-nvic_set_irq_level(int irq, int level) "NVIC external irq %d level set to %d"
-nvic_set_nmi_level(int level) "NVIC external NMI level set to %d"
-nvic_sysreg_read(uint64_t addr, uint32_t value, unsigned size) "NVIC sysreg read addr 0x%" PRIx64 " data 0x%" PRIx32 " size %u"
-nvic_sysreg_write(uint64_t addr, uint32_t value, unsigned size) "NVIC sysreg write addr 0x%" PRIx64 " data 0x%" PRIx32 " size %u"
-
 # heathrow_pic.c
 heathrow_write(uint64_t addr, unsigned int n, uint64_t value) "0x%"PRIx64" %u: 0x%"PRIx64
 heathrow_read(uint64_t addr, unsigned int n, uint64_t value) "0x%"PRIx64" %u: 0x%"PRIx64
-- 
2.47.2

Re: [PATCH 0/3] single-binary: compile hw/intc/arm* files once

[Philippe Mathieu-Daudé]

On 25/7/25 22:19, Pierrick Bouvier wrote:
> Move those files to hw/arm, as they depend on arm target code.
> 
> Pierrick Bouvier (3):
>    hw/arm/arm_gicv3_cpuif_common: move to hw/arm and compile only once
>    hw/arm/arm_gicv3_cpuif: move to hw/arm and compile only once
>    hw/arm/armv7m_nvic: move to hw/arm and compile only once
> 
>   hw/{intc => arm}/arm_gicv3_cpuif.c        |  2 +-
>   hw/{intc => arm}/arm_gicv3_cpuif_common.c |  2 +-
>   hw/{intc => arm}/armv7m_nvic.c            |  0

Alternatively add arm_common_ss in hw/intc/meson.build?

   arm_common_ss = ss.source_set()
   arm_common_ss.add(when: 'CONFIG_ARM_GIC',
                     if_true: files('arm_gicv3_cpuif_common.c'))
   arm_common_ss.add(when: 'CONFIG_ARM_GICV3',
                     if_true: files('arm_gicv3_cpuif.c'))
   arm_common_ss.add(when: 'CONFIG_ARM_V7M',
                     if_true: files('armv7m_nvic.c'))
   hw_common_arch += {'arm': arm_common_ss}

>   hw/arm/meson.build                        |  3 +
>   hw/arm/trace-events                       | 79 +++++++++++++++++++++++
>   hw/intc/meson.build                       |  3 -
>   hw/intc/trace-events                      | 79 -----------------------
>   7 files changed, 84 insertions(+), 84 deletions(-)
>   rename hw/{intc => arm}/arm_gicv3_cpuif.c (99%)
>   rename hw/{intc => arm}/arm_gicv3_cpuif_common.c (92%)
>   rename hw/{intc => arm}/armv7m_nvic.c (100%)
> 

Re: [PATCH 0/3] single-binary: compile hw/intc/arm* files once

[Pierrick Bouvier]

On 7/28/25 2:39 AM, Philippe Mathieu-Daudé wrote:
> On 25/7/25 22:19, Pierrick Bouvier wrote:
>> Move those files to hw/arm, as they depend on arm target code.
>>
>> Pierrick Bouvier (3):
>>     hw/arm/arm_gicv3_cpuif_common: move to hw/arm and compile only once
>>     hw/arm/arm_gicv3_cpuif: move to hw/arm and compile only once
>>     hw/arm/armv7m_nvic: move to hw/arm and compile only once
>>
>>    hw/{intc => arm}/arm_gicv3_cpuif.c        |  2 +-
>>    hw/{intc => arm}/arm_gicv3_cpuif_common.c |  2 +-
>>    hw/{intc => arm}/armv7m_nvic.c            |  0
> 
> Alternatively add arm_common_ss in hw/intc/meson.build?
> 
>     arm_common_ss = ss.source_set()
>     arm_common_ss.add(when: 'CONFIG_ARM_GIC',
>                       if_true: files('arm_gicv3_cpuif_common.c'))
>     arm_common_ss.add(when: 'CONFIG_ARM_GICV3',
>                       if_true: files('arm_gicv3_cpuif.c'))
>     arm_common_ss.add(when: 'CONFIG_ARM_V7M',
>                       if_true: files('armv7m_nvic.c'))
>     hw_common_arch += {'arm': arm_common_ss}
>

The problem with this approach is that we need to aggregate hw/arm and 
hw/intc arm related source sets, and the last line in your proposed 
change does not have this semantic.
Regarding meson, hw/intc subfolder is parsed *before* hw/arm (see 
hw/meson.build), so we can't reuse the same source set, defined in 
hw/arm/meson.build.

This old commit (7702e47c2) was the origin of having interrupt related 
code in a generic folder, but I don't really understand the rationale 
behind it to be honest. It seems to be an exception regarding all the 
rest of the codebase, thus the idea to bring back things where they belong.

I'm open to any other idea someone would have. Peter, without 
necessarily a working solution, do you have any preference on where 
those things should be?

>>    hw/arm/meson.build                        |  3 +
>>    hw/arm/trace-events                       | 79 +++++++++++++++++++++++
>>    hw/intc/meson.build                       |  3 -
>>    hw/intc/trace-events                      | 79 -----------------------
>>    7 files changed, 84 insertions(+), 84 deletions(-)
>>    rename hw/{intc => arm}/arm_gicv3_cpuif.c (99%)
>>    rename hw/{intc => arm}/arm_gicv3_cpuif_common.c (92%)
>>    rename hw/{intc => arm}/armv7m_nvic.c (100%)
>>
> 

Re: [PATCH 0/3] single-binary: compile hw/intc/arm* files once

[Philippe Mathieu-Daudé]

On 28/7/25 21:34, Pierrick Bouvier wrote:
> On 7/28/25 2:39 AM, Philippe Mathieu-Daudé wrote:
>> On 25/7/25 22:19, Pierrick Bouvier wrote:
>>> Move those files to hw/arm, as they depend on arm target code.
>>>
>>> Pierrick Bouvier (3):
>>>     hw/arm/arm_gicv3_cpuif_common: move to hw/arm and compile only once
>>>     hw/arm/arm_gicv3_cpuif: move to hw/arm and compile only once
>>>     hw/arm/armv7m_nvic: move to hw/arm and compile only once
>>>
>>>    hw/{intc => arm}/arm_gicv3_cpuif.c        |  2 +-
>>>    hw/{intc => arm}/arm_gicv3_cpuif_common.c |  2 +-
>>>    hw/{intc => arm}/armv7m_nvic.c            |  0
>>
>> Alternatively add arm_common_ss in hw/intc/meson.build?
>>
>>     arm_common_ss = ss.source_set()
>>     arm_common_ss.add(when: 'CONFIG_ARM_GIC',
>>                       if_true: files('arm_gicv3_cpuif_common.c'))
>>     arm_common_ss.add(when: 'CONFIG_ARM_GICV3',
>>                       if_true: files('arm_gicv3_cpuif.c'))
>>     arm_common_ss.add(when: 'CONFIG_ARM_V7M',
>>                       if_true: files('armv7m_nvic.c'))
>>     hw_common_arch += {'arm': arm_common_ss}
>>
> 
> The problem with this approach is that we need to aggregate hw/arm and 
> hw/intc arm related source sets, and the last line in your proposed 
> change does not have this semantic.
> Regarding meson, hw/intc subfolder is parsed *before* hw/arm (see hw/ 
> meson.build), so we can't reuse the same source set, defined in hw/arm/ 
> meson.build.
> 
> This old commit (7702e47c2) was the origin of having interrupt related 
> code in a generic folder, but I don't really understand the rationale 
> behind it to be honest. It seems to be an exception regarding all the 
> rest of the codebase, thus the idea to bring back things where they belong.

Yeah, you are right. What was suggested once was to move them to
target/arm/hw/, being architecture dependent / specific.

$ ls -l hw/arm | wc -l
       97

hw/arm/ contains board / soc / arm-specific hw and helpers (such
code loaders). Nothing wrong, I'm just wondering there is room for
improvements.

Personally I'd rather keep hw/arm/ for boards / soc, and move
ARM specific components (like GIC, NVIC, SMMU, timers to target/arm/hw/.

Anyhow, I don't object to your approach :) For this series:
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

> 
> I'm open to any other idea someone would have. Peter, without 
> necessarily a working solution, do you have any preference on where 
> those things should be?
> 
>>>    hw/arm/meson.build                        |  3 +
>>>    hw/arm/trace-events                       | 79 +++++++++++++++++++ 
>>> ++++
>>>    hw/intc/meson.build                       |  3 -
>>>    hw/intc/trace-events                      | 79 
>>> -----------------------
>>>    7 files changed, 84 insertions(+), 84 deletions(-)
>>>    rename hw/{intc => arm}/arm_gicv3_cpuif.c (99%)
>>>    rename hw/{intc => arm}/arm_gicv3_cpuif_common.c (92%)
>>>    rename hw/{intc => arm}/armv7m_nvic.c (100%)
>>>
>>
> 

Re: [PATCH 0/3] single-binary: compile hw/intc/arm* files once

[Pierrick Bouvier]

On 7/28/25 2:57 PM, Philippe Mathieu-Daudé wrote:
> On 28/7/25 21:34, Pierrick Bouvier wrote:
>> On 7/28/25 2:39 AM, Philippe Mathieu-Daudé wrote:
>>> On 25/7/25 22:19, Pierrick Bouvier wrote:
>>>> Move those files to hw/arm, as they depend on arm target code.
>>>>
>>>> Pierrick Bouvier (3):
>>>>      hw/arm/arm_gicv3_cpuif_common: move to hw/arm and compile only once
>>>>      hw/arm/arm_gicv3_cpuif: move to hw/arm and compile only once
>>>>      hw/arm/armv7m_nvic: move to hw/arm and compile only once
>>>>
>>>>     hw/{intc => arm}/arm_gicv3_cpuif.c        |  2 +-
>>>>     hw/{intc => arm}/arm_gicv3_cpuif_common.c |  2 +-
>>>>     hw/{intc => arm}/armv7m_nvic.c            |  0
>>>
>>> Alternatively add arm_common_ss in hw/intc/meson.build?
>>>
>>>      arm_common_ss = ss.source_set()
>>>      arm_common_ss.add(when: 'CONFIG_ARM_GIC',
>>>                        if_true: files('arm_gicv3_cpuif_common.c'))
>>>      arm_common_ss.add(when: 'CONFIG_ARM_GICV3',
>>>                        if_true: files('arm_gicv3_cpuif.c'))
>>>      arm_common_ss.add(when: 'CONFIG_ARM_V7M',
>>>                        if_true: files('armv7m_nvic.c'))
>>>      hw_common_arch += {'arm': arm_common_ss}
>>>
>>
>> The problem with this approach is that we need to aggregate hw/arm and
>> hw/intc arm related source sets, and the last line in your proposed
>> change does not have this semantic.
>> Regarding meson, hw/intc subfolder is parsed *before* hw/arm (see hw/
>> meson.build), so we can't reuse the same source set, defined in hw/arm/
>> meson.build.
>>
>> This old commit (7702e47c2) was the origin of having interrupt related
>> code in a generic folder, but I don't really understand the rationale
>> behind it to be honest. It seems to be an exception regarding all the
>> rest of the codebase, thus the idea to bring back things where they belong.
> 
> Yeah, you are right. What was suggested once was to move them to
> target/arm/hw/, being architecture dependent / specific.
> 
> $ ls -l hw/arm | wc -l
>         97
> 
> hw/arm/ contains board / soc / arm-specific hw and helpers (such
> code loaders). Nothing wrong, I'm just wondering there is room for
> improvements.
>

Sure, that makes sense.
GIC is a bit in the middle, as it's definitely an arm specific 
controller, and not a classical device. SMMU is directly in hw/arm for 
instance.

I'm really open to any structure Arm related developers would think is 
the best. It's just that moving a lot of files is always a pain for 
everyone, as it creates a lot of conflicts for people working on them 
currently, so I tried to minimize it here to target the strictly needed 
set of files only.

As well, I would prefer having a clean build system more than a clear 
filesystem structure, considering it's quite easy to jump into any 
definition automatically with your work editor nowadays, vs understand a 
meson.build file full of tricks and implicit dependencies where no tool 
can help you.

> Personally I'd rather keep hw/arm/ for boards / soc, and move
> ARM specific components (like GIC, NVIC, SMMU, timers to target/arm/hw/.
> 
> Anyhow, I don't object to your approach :) For this series:
> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> 
>>
>> I'm open to any other idea someone would have. Peter, without
>> necessarily a working solution, do you have any preference on where
>> those things should be?
>>
>>>>     hw/arm/meson.build                        |  3 +
>>>>     hw/arm/trace-events                       | 79 +++++++++++++++++++
>>>> ++++
>>>>     hw/intc/meson.build                       |  3 -
>>>>     hw/intc/trace-events                      | 79
>>>> -----------------------
>>>>     7 files changed, 84 insertions(+), 84 deletions(-)
>>>>     rename hw/{intc => arm}/arm_gicv3_cpuif.c (99%)
>>>>     rename hw/{intc => arm}/arm_gicv3_cpuif_common.c (92%)
>>>>     rename hw/{intc => arm}/armv7m_nvic.c (100%)
>>>>
>>>
>>
> 

Re: [PATCH 0/3] single-binary: compile hw/intc/arm* files once

[Peter Maydell]

On Mon, 28 Jul 2025 at 20:34, Pierrick Bouvier
<pierrick.bouvier@linaro.org> wrote:
> This old commit (7702e47c2) was the origin of having interrupt related
> code in a generic folder, but I don't really understand the rationale
> behind it to be honest. It seems to be an exception regarding all the
> rest of the codebase, thus the idea to bring back things where they belong.

Most devices are both (a) architecture specific and (b) a particular
kind of device (UART, ethernet controller, interrupt controller, etc).
The nature of a filesystem hierarchy is that we can't file them
in both ways at once. We picked "sort them by kind", which is why
all the interrupt controllers live in hw/intc, all the UARTS in
hw/char, ethernet controllers in hw/net, and so on. In this
breakdown of the world, hw/$ARCH is supposed to be for board models
and SoC models only.

The GICv3 and the NVIC are odd, because they are very closely
coupled to the CPU. (A few other interrupt controllers are also
like this, but many are not: for instance the GICv2 is a distinct
bit of hardware that communicates with the CPU over the IRQ and
FIQ lines only.)

One of my post-implementation regrets about GICv3 is that we
didn't really get the split between the GICv3 proper and its
CPU interface right. In hardware the GICv3 is an external device
and the CPU interface is part of the CPU, with a defined
protocol for talking between them. In QEMU we put all the
implementation of this in hw/intc/, and the code in arm_gicv3_cpuif.c
does some ad-hoc installing of hooks into the CPU.

For the GICv5 I'm trying to structure this in a cleaner way that
is closer to the hardware structure, so the CPU interface
will be code in target/arm/, with a clearly defined set of
functions that it calls to talk to the rest of the GIC that
lives in hw/intc/. (This would be too much upheaval to
retrofit to GICv3 though, I think.)

In a green-field design of M-profile we might have made
the NVIC be code in target/arm, and instead of a separate
device have the CPU object itself do this code. But at the
time it was written we didn't have the same QOM device
class setup we did at the time, and IIRC CPU objects
weren't a subclass of device.

> As well, I would prefer having a clean build system more than a clear
> filesystem structure, considering it's quite easy to jump into any
> definition automatically with your work editor nowadays, vs understand a
> meson.build file full of tricks and implicit dependencies where no tool
> can help you.

On the other hand, I prefer to have the source files in
a clear structure, because then you know where to find
things, and command line tools like grep etc are easier
to use. (I don't use editor jump-to-definition: I've never
felt the need to try to set it up.) Build system files on the
other hand are things that most people don't need to look at
or do more than very simple "add another file in the same pattern
as the existing ones", so it's not too bad if they accumulate
a little complexity.

Looking at hw/intc, there is a lot of use of specific_ss
here, so I suspect that these Arm interrupt controllers are
not going to be the only ones that are using target-dependent
code (there are 25 files which use CPUState, for instance).
So I think it's worth figuring out how to build these in
the right way where they are rather than saying that
various interrupt controller models should move to
a place where they don't logically belong because that happens
to be a folder where we have the build machinery for it.

thanks
-- PMM

Re: [PATCH 0/3] single-binary: compile hw/intc/arm* files once

[Pierrick Bouvier]

On 7/31/25 9:23 AM, Peter Maydell wrote:
> On Mon, 28 Jul 2025 at 20:34, Pierrick Bouvier
> <pierrick.bouvier@linaro.org> wrote:
>> This old commit (7702e47c2) was the origin of having interrupt related
>> code in a generic folder, but I don't really understand the rationale
>> behind it to be honest. It seems to be an exception regarding all the
>> rest of the codebase, thus the idea to bring back things where they belong.
> 
> Most devices are both (a) architecture specific and (b) a particular
> kind of device (UART, ethernet controller, interrupt controller, etc).
> The nature of a filesystem hierarchy is that we can't file them
> in both ways at once. We picked "sort them by kind", which is why
> all the interrupt controllers live in hw/intc, all the UARTS in
> hw/char, ethernet controllers in hw/net, and so on. In this
> breakdown of the world, hw/$ARCH is supposed to be for board models
> and SoC models only.
> 
> The GICv3 and the NVIC are odd, because they are very closely
> coupled to the CPU. (A few other interrupt controllers are also
> like this, but many are not: for instance the GICv2 is a distinct
> bit of hardware that communicates with the CPU over the IRQ and
> FIQ lines only.)
> 
> One of my post-implementation regrets about GICv3 is that we
> didn't really get the split between the GICv3 proper and its
> CPU interface right. In hardware the GICv3 is an external device
> and the CPU interface is part of the CPU, with a defined
> protocol for talking between them. In QEMU we put all the
> implementation of this in hw/intc/, and the code in arm_gicv3_cpuif.c
> does some ad-hoc installing of hooks into the CPU.
> 
> For the GICv5 I'm trying to structure this in a cleaner way that
> is closer to the hardware structure, so the CPU interface
> will be code in target/arm/, with a clearly defined set of
> functions that it calls to talk to the rest of the GIC that
> lives in hw/intc/. (This would be too much upheaval to
> retrofit to GICv3 though, I think.)
> 
> In a green-field design of M-profile we might have made
> the NVIC be code in target/arm, and instead of a separate
> device have the CPU object itself do this code. But at the
> time it was written we didn't have the same QOM device
> class setup we did at the time, and IIRC CPU objects
> weren't a subclass of device.
> 

Thanks for your answer Peter, it makes more clear for me what is the 
rationale between sorting the devices this way. It seems the root issue 
is the lack of proper interfacing between target cpu, and devices 
relying on it.

I don't expect any silver bullet to solve this, but we still need to 
move forward, so I'll share some options below.

>> As well, I would prefer having a clean build system more than a clear
>> filesystem structure, considering it's quite easy to jump into any
>> definition automatically with your work editor nowadays, vs understand a
>> meson.build file full of tricks and implicit dependencies where no tool
>> can help you.
> 
> On the other hand, I prefer to have the source files in
> a clear structure, because then you know where to find
> things, and command line tools like grep etc are easier
> to use. (I don't use editor jump-to-definition: I've never
> felt the need to try to set it up.) Build system files on the
> other hand are things that most people don't need to look at
> or do more than very simple "add another file in the same pattern
> as the existing ones", so it's not too bad if they accumulate
> a little complexity.
>

This maybe explains why QEMU is a bit messy regarding its build system 
architecture, because people are not interested into it. IMHO it's a 
mistake, because a clean build system architecture will usually force a 
clean software architecture, at least in terms of components and 
interfacing. This is what we see right now, with some of the fixes from 
the single binary being to extract proper API with fixed types, that 
allow components to communicate in a proper way.
Complexity does not help neither, because it makes meson build files 
hard to understand, and probably push back a lot of people from looking 
at this. It's sad considering meson first objective is precisely to 
limit the complexity of build systems.

Regarding the "modern" completion support, I recommend you take a look 
at it. Even though you wrote or reviewed most of the code you navigate 
in everyday, and thus don't need it, it has become a standard tool for 
any developer, like sanitizers or omniscient debugging. It's especially 
interesting since those tools are based on compilers (clangd is the 
standard for C/C++ nowadays) and not a bunch of clunky regexps.
It's even more interesting when you learn a new language, like Rust.

> Looking at hw/intc, there is a lot of use of specific_ss
> here, so I suspect that these Arm interrupt controllers are
> not going to be the only ones that are using target-dependent
> code (there are 25 files which use CPUState, for instance).
> So I think it's worth figuring out how to build these in
> the right way where they are rather than saying that
> various interrupt controller models should move to
> a place where they don't logically belong because that happens
> to be a folder where we have the build machinery for it.
> 

Coming back to our issue, I can see two ways to solve it in a short term:
- On build system: define target hw before generic ones, so we can reuse 
all the source sets defined there. This has the advantage to be usable 
by all others architectures.
- Move gic related fields to a substructure in arm cpu, and provide a 
simple accessor to it, like "cpu_gicv3(cpu)", breaking the dependency to 
cpu.h. Concerned fields would be: gic_num_lrs, gic_vpribits, 
gic_vprebits, gic_pribits.

As you'll be the one having the final word and merging this, which 
option would you prefer to see?

> thanks
> -- PMM

Re: [PATCH 0/3] single-binary: compile hw/intc/arm* files once

[Philippe Mathieu-Daudé]

On 31/7/25 20:30, Pierrick Bouvier wrote:
> On 7/31/25 9:23 AM, Peter Maydell wrote:
>> On Mon, 28 Jul 2025 at 20:34, Pierrick Bouvier
>> <pierrick.bouvier@linaro.org> wrote:
>>> This old commit (7702e47c2) was the origin of having interrupt related
>>> code in a generic folder, but I don't really understand the rationale
>>> behind it to be honest. It seems to be an exception regarding all the
>>> rest of the codebase, thus the idea to bring back things where they 
>>> belong.
>>
>> Most devices are both (a) architecture specific and (b) a particular
>> kind of device (UART, ethernet controller, interrupt controller, etc).
>> The nature of a filesystem hierarchy is that we can't file them
>> in both ways at once. We picked "sort them by kind", which is why
>> all the interrupt controllers live in hw/intc, all the UARTS in
>> hw/char, ethernet controllers in hw/net, and so on. In this
>> breakdown of the world, hw/$ARCH is supposed to be for board models
>> and SoC models only.
>>
>> The GICv3 and the NVIC are odd, because they are very closely
>> coupled to the CPU. (A few other interrupt controllers are also
>> like this, but many are not: for instance the GICv2 is a distinct
>> bit of hardware that communicates with the CPU over the IRQ and
>> FIQ lines only.)
>>
>> One of my post-implementation regrets about GICv3 is that we
>> didn't really get the split between the GICv3 proper and its
>> CPU interface right. In hardware the GICv3 is an external device
>> and the CPU interface is part of the CPU, with a defined
>> protocol for talking between them. In QEMU we put all the
>> implementation of this in hw/intc/, and the code in arm_gicv3_cpuif.c
>> does some ad-hoc installing of hooks into the CPU.
>>
>> For the GICv5 I'm trying to structure this in a cleaner way that
>> is closer to the hardware structure, so the CPU interface
>> will be code in target/arm/, with a clearly defined set of
>> functions that it calls to talk to the rest of the GIC that
>> lives in hw/intc/. (This would be too much upheaval to
>> retrofit to GICv3 though, I think.)
>>
>> In a green-field design of M-profile we might have made
>> the NVIC be code in target/arm, and instead of a separate
>> device have the CPU object itself do this code. But at the
>> time it was written we didn't have the same QOM device
>> class setup we did at the time, and IIRC CPU objects
>> weren't a subclass of device.


> Coming back to our issue, I can see two ways to solve it in a short term:
> - On build system: define target hw before generic ones, so we can reuse 
> all the source sets defined there. This has the advantage to be usable 
> by all others architectures.

That seems the cheaper / quicker way, isn't it?

> - Move gic related fields to a substructure in arm cpu, and provide a 
> simple accessor to it, like "cpu_gicv3(cpu)", breaking the dependency to 
> cpu.h. Concerned fields would be: gic_num_lrs, gic_vpribits, 
> gic_vprebits, gic_pribits.

FYI a previous attempt to disentangle GIC vs CPU with QOM:
https://lore.kernel.org/qemu-devel/20231212162935.42910-1-philmd@linaro.org/

Re: [PATCH 0/3] single-binary: compile hw/intc/arm* files once

[Pierrick Bouvier]

On 7/31/25 2:27 PM, Philippe Mathieu-Daudé wrote:
> On 31/7/25 20:30, Pierrick Bouvier wrote:
>> On 7/31/25 9:23 AM, Peter Maydell wrote:
>>> On Mon, 28 Jul 2025 at 20:34, Pierrick Bouvier
>>> <pierrick.bouvier@linaro.org> wrote:
>>>> This old commit (7702e47c2) was the origin of having interrupt related
>>>> code in a generic folder, but I don't really understand the rationale
>>>> behind it to be honest. It seems to be an exception regarding all the
>>>> rest of the codebase, thus the idea to bring back things where they
>>>> belong.
>>>
>>> Most devices are both (a) architecture specific and (b) a particular
>>> kind of device (UART, ethernet controller, interrupt controller, etc).
>>> The nature of a filesystem hierarchy is that we can't file them
>>> in both ways at once. We picked "sort them by kind", which is why
>>> all the interrupt controllers live in hw/intc, all the UARTS in
>>> hw/char, ethernet controllers in hw/net, and so on. In this
>>> breakdown of the world, hw/$ARCH is supposed to be for board models
>>> and SoC models only.
>>>
>>> The GICv3 and the NVIC are odd, because they are very closely
>>> coupled to the CPU. (A few other interrupt controllers are also
>>> like this, but many are not: for instance the GICv2 is a distinct
>>> bit of hardware that communicates with the CPU over the IRQ and
>>> FIQ lines only.)
>>>
>>> One of my post-implementation regrets about GICv3 is that we
>>> didn't really get the split between the GICv3 proper and its
>>> CPU interface right. In hardware the GICv3 is an external device
>>> and the CPU interface is part of the CPU, with a defined
>>> protocol for talking between them. In QEMU we put all the
>>> implementation of this in hw/intc/, and the code in arm_gicv3_cpuif.c
>>> does some ad-hoc installing of hooks into the CPU.
>>>
>>> For the GICv5 I'm trying to structure this in a cleaner way that
>>> is closer to the hardware structure, so the CPU interface
>>> will be code in target/arm/, with a clearly defined set of
>>> functions that it calls to talk to the rest of the GIC that
>>> lives in hw/intc/. (This would be too much upheaval to
>>> retrofit to GICv3 though, I think.)
>>>
>>> In a green-field design of M-profile we might have made
>>> the NVIC be code in target/arm, and instead of a separate
>>> device have the CPU object itself do this code. But at the
>>> time it was written we didn't have the same QOM device
>>> class setup we did at the time, and IIRC CPU objects
>>> weren't a subclass of device.
> 
> 
>> Coming back to our issue, I can see two ways to solve it in a short term:
>> - On build system: define target hw before generic ones, so we can reuse
>> all the source sets defined there. This has the advantage to be usable
>> by all others architectures.
> 
> That seems the cheaper / quicker way, isn't it?
>

Yes, and beyond cpu->* usage, there is a lot of cpregs involved too.
I'll try this option then (build system one).

>> - Move gic related fields to a substructure in arm cpu, and provide a
>> simple accessor to it, like "cpu_gicv3(cpu)", breaking the dependency to
>> cpu.h. Concerned fields would be: gic_num_lrs, gic_vpribits,
>> gic_vprebits, gic_pribits.
> 
> FYI a previous attempt to disentangle GIC vs CPU with QOM:
> https://lore.kernel.org/qemu-devel/20231212162935.42910-1-philmd@linaro.org/
> 

Re: [PATCH 0/3] single-binary: compile hw/intc/arm* files once

[Peter Maydell]

On Thu, 31 Jul 2025 at 19:30, Pierrick Bouvier
<pierrick.bouvier@linaro.org> wrote:
> Regarding the "modern" completion support, I recommend you take a look
> at it. Even though you wrote or reviewed most of the code you navigate
> in everyday, and thus don't need it, it has become a standard tool for
> any developer, like sanitizers or omniscient debugging. It's especially
> interesting since those tools are based on compilers (clangd is the
> standard for C/C++ nowadays) and not a bunch of clunky regexps.
> It's even more interesting when you learn a new language, like Rust.

I do actually have clangd enabled at the moment in emacs:
but my experience is not good, because typically what happens
is that clangd runs itself out of memory and falls over
fairly frequently, or it produces obscure error messages like
"LSP :: Error from the Language Server: trying to get AST for
non-added document (Invalid Parameter)"...

So I mostly continue to investigate code the way I always have
done, with grep.

-- PMM

Re: [PATCH 0/3] single-binary: compile hw/intc/arm* files once

[Pierrick Bouvier]

On 8/1/25 1:34 AM, Peter Maydell wrote:
> On Thu, 31 Jul 2025 at 19:30, Pierrick Bouvier
> <pierrick.bouvier@linaro.org> wrote:
>> Regarding the "modern" completion support, I recommend you take a look
>> at it. Even though you wrote or reviewed most of the code you navigate
>> in everyday, and thus don't need it, it has become a standard tool for
>> any developer, like sanitizers or omniscient debugging. It's especially
>> interesting since those tools are based on compilers (clangd is the
>> standard for C/C++ nowadays) and not a bunch of clunky regexps.
>> It's even more interesting when you learn a new language, like Rust.
> 
> I do actually have clangd enabled at the moment in emacs:
> but my experience is not good, because typically what happens
> is that clangd runs itself out of memory and falls over
> fairly frequently, or it produces obscure error messages like
> "LSP :: Error from the Language Server: trying to get AST for
> non-added document (Invalid Parameter)"...
> 
> So I mostly continue to investigate code the way I always have
> done, with grep.
>

By any chance, are you using an old version of clangd (or an old 
distro)? It has been a few years since I didn't run into any issue with 
it, and it's quite easy to update it using llvm apt repositories without 
updating your whole system [1].

[1] https://apt.llvm.org/

> -- PMM

Re: [PATCH 0/3] single-binary: compile hw/intc/arm* files once

[Peter Maydell]

On Fri, 1 Aug 2025 at 17:31, Pierrick Bouvier
<pierrick.bouvier@linaro.org> wrote:
>
> On 8/1/25 1:34 AM, Peter Maydell wrote:
> > On Thu, 31 Jul 2025 at 19:30, Pierrick Bouvier
> > <pierrick.bouvier@linaro.org> wrote:
> >> Regarding the "modern" completion support, I recommend you take a look
> >> at it. Even though you wrote or reviewed most of the code you navigate
> >> in everyday, and thus don't need it, it has become a standard tool for
> >> any developer, like sanitizers or omniscient debugging. It's especially
> >> interesting since those tools are based on compilers (clangd is the
> >> standard for C/C++ nowadays) and not a bunch of clunky regexps.
> >> It's even more interesting when you learn a new language, like Rust.
> >
> > I do actually have clangd enabled at the moment in emacs:
> > but my experience is not good, because typically what happens
> > is that clangd runs itself out of memory and falls over
> > fairly frequently, or it produces obscure error messages like
> > "LSP :: Error from the Language Server: trying to get AST for
> > non-added document (Invalid Parameter)"...
> >
> > So I mostly continue to investigate code the way I always have
> > done, with grep.
> >
>
> By any chance, are you using an old version of clangd (or an old
> distro)? It has been a few years since I didn't run into any issue with
> it, and it's quite easy to update it using llvm apt repositories without
> updating your whole system [1].

I use the Ubuntu 24.04 version. In general I try to avoid
using tooling that isn't packaged by the distro: it
tends to result in headaches later on.

-- PMM

Re: [PATCH 0/3] single-binary: compile hw/intc/arm* files once

[Pierrick Bouvier]

On 8/1/25 9:38 AM, Peter Maydell wrote:
> On Fri, 1 Aug 2025 at 17:31, Pierrick Bouvier
> <pierrick.bouvier@linaro.org> wrote:
>>
>> On 8/1/25 1:34 AM, Peter Maydell wrote:
>>> On Thu, 31 Jul 2025 at 19:30, Pierrick Bouvier
>>> <pierrick.bouvier@linaro.org> wrote:
>>>> Regarding the "modern" completion support, I recommend you take a look
>>>> at it. Even though you wrote or reviewed most of the code you navigate
>>>> in everyday, and thus don't need it, it has become a standard tool for
>>>> any developer, like sanitizers or omniscient debugging. It's especially
>>>> interesting since those tools are based on compilers (clangd is the
>>>> standard for C/C++ nowadays) and not a bunch of clunky regexps.
>>>> It's even more interesting when you learn a new language, like Rust.
>>>
>>> I do actually have clangd enabled at the moment in emacs:
>>> but my experience is not good, because typically what happens
>>> is that clangd runs itself out of memory and falls over
>>> fairly frequently, or it produces obscure error messages like
>>> "LSP :: Error from the Language Server: trying to get AST for
>>> non-added document (Invalid Parameter)"...
>>>
>>> So I mostly continue to investigate code the way I always have
>>> done, with grep.
>>>
>>
>> By any chance, are you using an old version of clangd (or an old
>> distro)? It has been a few years since I didn't run into any issue with
>> it, and it's quite easy to update it using llvm apt repositories without
>> updating your whole system [1].
> 
> I use the Ubuntu 24.04 version. In general I try to avoid
> using tooling that isn't packaged by the distro: it
> tends to result in headaches later on.
>

You should be good with it I think.
Maybe you can try to delete clangd caches, in case there is a problem there:
- ~/.cache/clangd/index/
- (in qemu build folder): build/.cache/clangd/index

> -- PMM