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

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%)
>

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%)
>>
> 

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

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

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

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

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

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

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/

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

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%)
>>>
>>
> 

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%)
>>>>
>>>
>>
>