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

[Pierrick Bouvier <pierrick.bouvier@linaro.org>]

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