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

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

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/
>