Hyperlaunch/dom0less code sharing

Hyperlaunch/dom0less code sharing

[Alejandro Vallejo]

Hi,

(There's a TL;DR at the end)

While working on preparing and reworking the hyperlaunch series for
upstreaming it's slowly becoming apparent the degree of duplication with
dom0less.

Oleksii's latest effort to move all that code into common[*] (see
ad03faa942b9("xen/common: dom0less: make some...) makes this even clearer.
There are 1:1 relationships for every key data strucutre, and by deviating
we're overcomplicating the ability to share code.

  [*] https://lore.kernel.org/xen-devel/cover.1746468003.git.oleksii.kurochko@gmail.com/

    dom0less           Hyperlaunch
    ------------------------------
    kernel_info        boot_domain
    bootmodule         boot_module
    bootmodule_kind   bootmod_type
    membanks                memmap
    bootinfo             boot_info

The difficulty in code sharing is not just unfortunate from a vague sense of
elegance or neatness. Having different code paths parsing the same DT bindings
means it's a matter of time before x86 and all other Xen ports have different
bindings, which would would only worsen the situation wrt code sharing and user
confusion.
 
I've been trying to get _somewhere_ in using parts of dom0less on x86
and develop a credible PoC that highlights the use of dom0less parsing
code paths. The results are interesting.

While I didn't get to a full integration in the hyperlaunch series as I hoped
due to time constraints I did get far enough to:

  1. Replace boot_module, boot_domain and bootmod_type with their dom0less
     counterparts (pending some cleanup).
  2. Isolate binding parsing code in common/device-tree so it's dettached from
     the not-so-common dom0less domain building logic in dom0less-build.c
  3. Do early module kind detection from x86 using code in (2).
  4. Do late binding parsing also using code in (2) after unflattening the DTB.

And it works well enough under QEMU to populate boot_info to a first
approximation. It's missing hyperlaunch-specific bindings (like "domid"
or "mode"), but that's just a matter of adding them to the already
existing per-arch binding parser ("mode", maybe, would be a candidate
for this) or retrofit them in dom0less ("domid" is a very clear
candidate for this) and integrating in the larger series to be able to
actually boot domains.

The PoC does not go all the way due to time constraints, as I said, but
I think it goes far enough to convince me it's both feasible and
beneficial to go in this direction rather than that of a full
reimplementation on x86, specially seeing how Oleksii already aims to
have full code reuse on riscv.

A brave new world would reuse all data (including bootinfo) and code
(bootfdt.c/bootinfo.c), but I couldn't get that far, and I don't think
I'll be able to in a timely manner. IOW: I compiled-in device-tree.c,
but NOT bootfdt.c or bootinfo.c, or any of the others. I merely
extracted from those files the binding parsing bits of interest.

It'd be nice to use them, but the domain construction logic is just too
different at present. As for the code I tested with,  I need to do some serious
cleanup before it's ready for sharing, and even moreso for review, but before I
go through that I'd like to reach consensus on the following points before
investing any more of my time working on the side.

TL;DR:

I think we should aim to share binding code wherever possible, using common
datastructures (kernel_info and bootmodule) as dumping ground for the results
of the binding parsing functions. I seek agreement on the following 3 points
for the end goal of DTB multidomain boots on x86 before I start slicing
my hacks into reasonable chunks.

  1. We want common data structures, with arch-specific fields to hold
     information from xen,domain DT nodes
  2. We want to have a single collection of DTB parsers in the code.
  3. We want to operate on the unflattened DTB for the majority of parsing.
    (plus a minimal version on the FDT in order to bootstrap, also common)

(2) and (3) are tightly related. There's many reasons for wanting to use the
unflattened blobs as much as possible. They range from quirks in specific "dtc"
versions, to complexities parsing phandles, to corner cases involving duplicate
properties (i.e: due to .dtsi files), etc. Unflattening an FDT brings a
lots of "maybe-ok-after-sanitising" FDTs back into canonically correct DTs.

I'll share the PoC code as soon as as it's in a presentable state.
Hopefully by the end of the week. But I'm sending this ahead of time to
start collecting thoughts right away.

So. Thoughts?

Cheers,
Alejandro

Re: Hyperlaunch/dom0less code sharing

[Jan Beulich]

On 21.05.2025 16:35, Alejandro Vallejo wrote:
> I think we should aim to share binding code wherever possible, using common
> datastructures (kernel_info and bootmodule) as dumping ground for the results
> of the binding parsing functions. I seek agreement on the following 3 points
> for the end goal of DTB multidomain boots on x86 before I start slicing
> my hacks into reasonable chunks.
> 
>   1. We want common data structures, with arch-specific fields to hold
>      information from xen,domain DT nodes
>   2. We want to have a single collection of DTB parsers in the code.
>   3. We want to operate on the unflattened DTB for the majority of parsing.
>     (plus a minimal version on the FDT in order to bootstrap, also common)

+1 on all three, with the caveat that I'm far from being an expert on DT.

Jan

> (2) and (3) are tightly related. There's many reasons for wanting to use the
> unflattened blobs as much as possible. They range from quirks in specific "dtc"
> versions, to complexities parsing phandles, to corner cases involving duplicate
> properties (i.e: due to .dtsi files), etc. Unflattening an FDT brings a
> lots of "maybe-ok-after-sanitising" FDTs back into canonically correct DTs.
> 
> I'll share the PoC code as soon as as it's in a presentable state.
> Hopefully by the end of the week. But I'm sending this ahead of time to
> start collecting thoughts right away.
> 
> So. Thoughts?
> 
> Cheers,
> Alejandro

Re: Hyperlaunch/dom0less code sharing

[Stefano Stabellini]

On Wed, 21 May 2025, Jan Beulich wrote:
> On 21.05.2025 16:35, Alejandro Vallejo wrote:
> > I think we should aim to share binding code wherever possible, using common
> > datastructures (kernel_info and bootmodule) as dumping ground for the results
> > of the binding parsing functions. I seek agreement on the following 3 points
> > for the end goal of DTB multidomain boots on x86 before I start slicing
> > my hacks into reasonable chunks.
> > 
> >   1. We want common data structures, with arch-specific fields to hold
> >      information from xen,domain DT nodes
> >   2. We want to have a single collection of DTB parsers in the code.
> >   3. We want to operate on the unflattened DTB for the majority of parsing.
> >     (plus a minimal version on the FDT in order to bootstrap, also common)
> 
> +1 on all three, with the caveat that I'm far from being an expert on DT.

+1 from me as well

Re: Hyperlaunch/dom0less code sharing

[Daniel P. Smith]

On 5/21/25 10:35, Alejandro Vallejo wrote:
> Hi,
> 
> (There's a TL;DR at the end)
> 
> While working on preparing and reworking the hyperlaunch series for
> upstreaming it's slowly becoming apparent the degree of duplication with
> dom0less.

Yes, this was by design so that when we got to the point of convergence 
it would be apparent where the commonalities are and thus be collapsed.

> Oleksii's latest effort to move all that code into common[*] (see
> ad03faa942b9("xen/common: dom0less: make some...) makes this even clearer.
> There are 1:1 relationships for every key data strucutre, and by deviating
> we're overcomplicating the ability to share code.
> 
>    [*] https://lore.kernel.org/xen-devel/cover.1746468003.git.oleksii.kurochko@gmail.com/
> 
>      dom0less           Hyperlaunch
>      ------------------------------
>      kernel_info        boot_domain
>      bootmodule         boot_module
>      bootmodule_kind   bootmod_type
>      membanks                memmap
>      bootinfo             boot_info

If you go back, you will see less of these differences. A lot of the 
variations have been the results of reviewer's request. And that goes to 
the fact that dom0less was developed with Arm mentality in terminology, 
eg. memory banks verse memory map.

> The difficulty in code sharing is not just unfortunate from a vague sense of
> elegance or neatness. Having different code paths parsing the same DT bindings
> means it's a matter of time before x86 and all other Xen ports have different
> bindings, which would would only worsen the situation wrt code sharing and user
> confusion.

Only if we allowed it, but with that said there are subtleties between 
the arch that will require variation. Such as mode, which is primarily 
an x86 specific.

> I've been trying to get _somewhere_ in using parts of dom0less on x86
> and develop a credible PoC that highlights the use of dom0less parsing
> code paths. The results are interesting.
> 
> While I didn't get to a full integration in the hyperlaunch series as I hoped
> due to time constraints I did get far enough to:
> 
>    1. Replace boot_module, boot_domain and bootmod_type with their dom0less
>       counterparts (pending some cleanup).
>    2. Isolate binding parsing code in common/device-tree so it's dettached from
>       the not-so-common dom0less domain building logic in dom0less-build.c
>    3. Do early module kind detection from x86 using code in (2).
>    4. Do late binding parsing also using code in (2) after unflattening the DTB.
> 
> And it works well enough under QEMU to populate boot_info to a first
> approximation. It's missing hyperlaunch-specific bindings (like "domid"
> or "mode"), but that's just a matter of adding them to the already
> existing per-arch binding parser ("mode", maybe, would be a candidate
> for this) or retrofit them in dom0less ("domid" is a very clear
> candidate for this) and integrating in the larger series to be able to
> actually boot domains.
> 
> The PoC does not go all the way due to time constraints, as I said, but
> I think it goes far enough to convince me it's both feasible and
> beneficial to go in this direction rather than that of a full
> reimplementation on x86, specially seeing how Oleksii already aims to
> have full code reuse on riscv.
> 
> A brave new world would reuse all data (including bootinfo) and code
> (bootfdt.c/bootinfo.c), but I couldn't get that far, and I don't think
> I'll be able to in a timely manner. IOW: I compiled-in device-tree.c,
> but NOT bootfdt.c or bootinfo.c, or any of the others. I merely
> extracted from those files the binding parsing bits of interest.
> 
> It'd be nice to use them, but the domain construction logic is just too
> different at present. As for the code I tested with,  I need to do some serious
> cleanup before it's ready for sharing, and even moreso for review, but before I
> go through that I'd like to reach consensus on the following points before
> investing any more of my time working on the side.
> 
> TL;DR:
> 
> I think we should aim to share binding code wherever possible, using common
> datastructures (kernel_info and bootmodule) as dumping ground for the results
> of the binding parsing functions. I seek agreement on the following 3 points
> for the end goal of DTB multidomain boots on x86 before I start slicing
> my hacks into reasonable chunks.
> 
>    1. We want common data structures, with arch-specific fields to hold
>       information from xen,domain DT nodes
>    2. We want to have a single collection of DTB parsers in the code.
>    3. We want to operate on the unflattened DTB for the majority of parsing.
>      (plus a minimal version on the FDT in order to bootstrap, also common)

As for 3, I can repost my original analysis that went to the working 
group on why using this is not the best idea. Doing 3 would require 
doing at least two, if not three passes on the DTB for x86 with zero 
benefit/need since, unlike Arm, we never have to read from it after 
boot. The way the x86 parser is today, we are walking the DTB only once.

What I would suggest for 2 is that, perhaps, it might be an opportune 
time to review the existing DTB parsing code. Providing a common 
interface to parse standard/spec DTB structures regardless if it is 
coming from an FTB or via the FTB index, aka "unflattened" DTB. Doing so 
would enable a complete reuse within the DTB parsers and remove then 
need for 3.


> (2) and (3) are tightly related. There's many reasons for wanting to use the
> unflattened blobs as much as possible. They range from quirks in specific "dtc"
> versions, to complexities parsing phandles, to corner cases involving duplicate
> properties (i.e: due to .dtsi files), etc. Unflattening an FDT brings a
> lots of "maybe-ok-after-sanitising" FDTs back into canonically correct DTs.
> 
> I'll share the PoC code as soon as as it's in a presentable state.
> Hopefully by the end of the week. But I'm sending this ahead of time to
> start collecting thoughts right away.
> 
> So. Thoughts?


v/r,
dps

Re: Hyperlaunch/dom0less code sharing

[Daniel P. Smith]

On 5/21/25 11:31, Daniel P. Smith wrote:

> As for 3, I can repost my original analysis that went to the working 
> group on why using this is not the best idea. Doing 3 would require 
> doing at least two, if not three passes on the DTB for x86 with zero 
> benefit/need since, unlike Arm, we never have to read from it after 
> boot. The way the x86 parser is today, we are walking the DTB only once.
> 
> What I would suggest for 2 is that, perhaps, it might be an opportune 
> time to review the existing DTB parsing code. Providing a common 
> interface to parse standard/spec DTB structures regardless if it is 
> coming from an FTB or via the FTB index, aka "unflattened" DTB. Doing so 
> would enable a complete reuse within the DTB parsers and remove then 
> need for 3.

Apologies, I did not CC anyone on the posting of the original analysis. 
It is posted to xen-devel as "Hyperlaunch Device Tree Discussion".

v/r,
dps

Re: Hyperlaunch/dom0less code sharing

[Alejandro Vallejo]

Hi,

On Wed May 21, 2025 at 5:31 PM CEST, Daniel P. Smith wrote:
> On 5/21/25 10:35, Alejandro Vallejo wrote:
>> Hi,
>> 
>> (There's a TL;DR at the end)
>> 
>> While working on preparing and reworking the hyperlaunch series for
>> upstreaming it's slowly becoming apparent the degree of duplication with
>> dom0less.
>
> Yes, this was by design so that when we got to the point of convergence 
> it would be apparent where the commonalities are and thus be collapsed.

I'd say they are already fairly apparent. So long as we're all in
agreement I'd like to collapse them sooner when the differences are
small rather than later when it'll be a bigger PITA.

I'll prepare and send what I have so far. It'll all be code motion and
non-functional changes to remove struct duplication.

>
>> Oleksii's latest effort to move all that code into common[*] (see
>> ad03faa942b9("xen/common: dom0less: make some...) makes this even clearer.
>> There are 1:1 relationships for every key data strucutre, and by deviating
>> we're overcomplicating the ability to share code.
>> 
>>    [*] https://lore.kernel.org/xen-devel/cover.1746468003.git.oleksii.kurochko@gmail.com/
>> 
>>      dom0less           Hyperlaunch
>>      ------------------------------
>>      kernel_info        boot_domain
>>      bootmodule         boot_module
>>      bootmodule_kind   bootmod_type
>>      membanks                memmap
>>      bootinfo             boot_info
>
> If you go back, you will see less of these differences. A lot of the 
> variations have been the results of reviewer's request. And that goes to 
> the fact that dom0less was developed with Arm mentality in terminology, 
> eg. memory banks verse memory map.

bootinfo and banks/maps are more complicated to merge (I do want to
merge them, though, but one elephant at a time). All the others can be
merged without much hassle with minor code adjustments.

>
>> The difficulty in code sharing is not just unfortunate from a vague sense of
>> elegance or neatness. Having different code paths parsing the same DT bindings
>> means it's a matter of time before x86 and all other Xen ports have different
>> bindings, which would would only worsen the situation wrt code sharing and user
>> confusion.
>
> Only if we allowed it,

Granted. But mistakes happen, and if detected late enough you end up
with aberrations like x86's compat layer for hypercall parsing. I know I
don't want to see that kind of thing ever again if I can help it.

> but with that said there are subtleties between the arch that will
> require variation. Such as mode, which is primarily an x86 specific.

Yes. Common code can't mean exclusively common. Fortunately, dom0less in
common gained provisions for per-ach bindings (see arch_create_domUs()
in staging). With those hunks extracted (keeping the arch hook in them),
x86 could use the same, keeping private bindings where appropriate.

>
>> I've been trying to get _somewhere_ in using parts of dom0less on x86
>> and develop a credible PoC that highlights the use of dom0less parsing
>> code paths. The results are interesting.
>> 
>> While I didn't get to a full integration in the hyperlaunch series as I hoped
>> due to time constraints I did get far enough to:
>> 
>>    1. Replace boot_module, boot_domain and bootmod_type with their dom0less
>>       counterparts (pending some cleanup).
>>    2. Isolate binding parsing code in common/device-tree so it's dettached from
>>       the not-so-common dom0less domain building logic in dom0less-build.c
>>    3. Do early module kind detection from x86 using code in (2).
>>    4. Do late binding parsing also using code in (2) after unflattening the DTB.
>> 
>> And it works well enough under QEMU to populate boot_info to a first
>> approximation. It's missing hyperlaunch-specific bindings (like "domid"
>> or "mode"), but that's just a matter of adding them to the already
>> existing per-arch binding parser ("mode", maybe, would be a candidate
>> for this) or retrofit them in dom0less ("domid" is a very clear
>> candidate for this) and integrating in the larger series to be able to
>> actually boot domains.
>> 
>> The PoC does not go all the way due to time constraints, as I said, but
>> I think it goes far enough to convince me it's both feasible and
>> beneficial to go in this direction rather than that of a full
>> reimplementation on x86, specially seeing how Oleksii already aims to
>> have full code reuse on riscv.
>> 
>> A brave new world would reuse all data (including bootinfo) and code
>> (bootfdt.c/bootinfo.c), but I couldn't get that far, and I don't think
>> I'll be able to in a timely manner. IOW: I compiled-in device-tree.c,
>> but NOT bootfdt.c or bootinfo.c, or any of the others. I merely
>> extracted from those files the binding parsing bits of interest.
>> 
>> It'd be nice to use them, but the domain construction logic is just too
>> different at present. As for the code I tested with,  I need to do some serious
>> cleanup before it's ready for sharing, and even moreso for review, but before I
>> go through that I'd like to reach consensus on the following points before
>> investing any more of my time working on the side.
>> 
>> TL;DR:
>> 
>> I think we should aim to share binding code wherever possible, using common
>> datastructures (kernel_info and bootmodule) as dumping ground for the results
>> of the binding parsing functions. I seek agreement on the following 3 points
>> for the end goal of DTB multidomain boots on x86 before I start slicing
>> my hacks into reasonable chunks.
>> 
>>    1. We want common data structures, with arch-specific fields to hold
>>       information from xen,domain DT nodes
>>    2. We want to have a single collection of DTB parsers in the code.
>>    3. We want to operate on the unflattened DTB for the majority of parsing.
>>      (plus a minimal version on the FDT in order to bootstrap, also common)
>
> As for 3, I can repost my original analysis that went to the working 
> group on why using this is not the best idea. Doing 3 would require 
> doing at least two, if not three passes on the DTB for x86 with zero 
> benefit/need since, unlike Arm, we never have to read from it after 
> boot. The way the x86 parser is today, we are walking the DTB only once.

Note that some libfdt wrappers are deceptive and have hideous time
complexities. Doing one pass might not mean a monotonically increasing
cursor. Regardless, DTBs are always quite small (particularly so in
x86), so the time complexity of the parsing algorithm is of little
consequence. We could do 512 passes and the time it would take would
still be negligible.

>
> What I would suggest for 2 is that, perhaps, it might be an opportune 
> time to review the existing DTB parsing code. Providing a common 
> interface to parse standard/spec DTB structures regardless if it is 
> coming from an FTB or via the FTB index, aka "unflattened" DTB. Doing so 
> would enable a complete reuse within the DTB parsers and remove then 
> need for 3.

The biggest reason for using the DTB unflattened is (imo) having arm and
x86 parsing the same data structure. The unflattened tree is not merely
an FDT with pointers. There's logic to merge nodes with the same names,
remove duplicates, etc. A "quirky" DTB (e.g: with overlapping nodes),
would thus behave differently on arm and x86 unless they both use the
FDT or the unflattened DT.

Furthermore, parsing strictly in the order you find properties in
creates a danger to synthesise different systems when fed DTBs that have
properties in different orders. imagebuilder could be instructed to
reduce the danger of this by having a canonical order of properties, but
I really dislike having room for diverging interpretations of identical
source data. This isn't necessarily an issue with FDT parsing per se,
but it is with the way it's been done in the existing series, whereas
the code in dom0less looks up properties in a specific order.

>
>> (2) and (3) are tightly related. There's many reasons for wanting to use the
>> unflattened blobs as much as possible. They range from quirks in specific "dtc"
>> versions, to complexities parsing phandles, to corner cases involving duplicate
>> properties (i.e: due to .dtsi files), etc. Unflattening an FDT brings a
>> lots of "maybe-ok-after-sanitising" FDTs back into canonically correct DTs.
>> 
>> I'll share the PoC code as soon as as it's in a presentable state.
>> Hopefully by the end of the week. But I'm sending this ahead of time to
>> start collecting thoughts right away.
>> 
>> So. Thoughts?
>
>
> v/r,
> dps

All this said, the analysis (thanks for sharing) seems still relevant
and also seems like a reasonable goal for all architectures, but having
everyone parsing the DTB in the exact same way leads to far better
predictability. Once all the code is in common and in use, it'll be a
lot easier to simply modify arm to use the FDT on the grounds of keeping
arch-symmetry and the drop of code it'd mean for x86.

For the time being, however, I'm more interested in getting staging to a
working state where it can boot multiple domains off a DTB, without
endangering arch-symmetry. Then the rest is refinement and optimisation.

Cheers,
Alejandro

[PATCH 00/19] Allow x86 to unflatten DTs

[Alejandro Vallejo]

This is the aftermath of this discussion:

  https://lore.kernel.org/xen-devel/DA1WWRUQLCAG.ZTVR1HXJ85V0@amd.com/https://lore.kernel.org/xen-devel/DA1WWRUQLCAG.ZTVR1HXJ85V0@amd.com/

It's a first round of cleanup and preparation to have a much easier time
later when integrating dom0less boot into hyperlaunch.

The refactor on device-tree/ is _fine_ by I'm open to other suggestions
to achieve the same thing. In particular, after this series x86 can
unflatten the DT host device tree when it has CONFIG_DOM0LESS_BOOT set,
which enables the builder to use factored-out functions from
dom0less-build.c (not done here).

The diffstat is deceptive because I renamed a large file and then
created a new file with the same name. There aren't that many LoC
changes.

I wrote it as a series to keep things focused, but there's a number of
independent chunks.

  * Patches 1 to 7 are strict (hopefully) uncontroversial cleanups.

  * Patches 8 and 9 add minor missing bits to bootmodule needed by x86.

  * Patches 10 and 11 are BIG, but trivial. They are strict renames of
    boot_module to bootmodule, and equally trivial adjustments to the 
    fields (e.g: s/kernel/kernel_bootmodule or s/relocated/arch.relocated/)

  * Patches 12 to 16 try to put some order inside device-tree/. Despite
    their diffstat it's all code motion without functional changes.

  * Patch 17 is the cornerstone of allowing x86 to unflatten DTs,
    otherwise there's the world's entire supply of compile time errors
    due to x86 assuming device_t to be pci_dev.

  * Patches 18 and 19 are inconsequential here, but enables future
    patches in this direction to be gated by a selectable option in
    Kconfig. i.e: it would replace the current CONFIG_DOMAIN_BUILDER in
    the hyperlaunch series. In time, we'll want to rename it to
    CONFIG_MULTIDOMAIN_BUILDER, or CONFIG_PREDOMAINS, or something along
    those lines. For the time being CONFIG_BOOT_DOM0LESS can mean
    CONFIG_BOOT_HYPERLAUNCH on x86 without much of value being lost.

I'd like to re-touch the dom0less help message, as it's written very
confusingly, but I'll leave that for later series.

Alejandro Vallejo (19):
  licence: Add missing SPDX line to bootfdt.h
  x86: Add missing pci_dev forward declaration in asm/pci.h
  riscv: Add missing forward declaration to intc.h
  xen: Add missing forward declaration to  btcpupools_get_domain_pool_id
  arm: Remove dependencies with membank(s) definitions from setup.h
  xen: Clean up asm-generic/device.h
  arm/gnttab: Break cycle between asm/grant_table.h and
    xen/grant_table.h
  xen/dt: Add BOOTMOD_MICROCODE
  x86: Preinitialise all modules to be of kind BOOTMOD_UNKNOWN
  x86: Replace boot_module with bootmodule
  x86: Replace boot_domain with kernel_info
  xen/dt: Move bootfdt functions to xen/bootfdt.h
  xen/dt: Move bootinfo functions to a new bootinfo.h
  xen/dt: Rename bootfdt.c -> bootinfo-fdt.c
  xen/dt: Move bootinfo-independent helpers out of bootinfo-fdt.c
  xen/dt: Extract helper to map nodes to module kinds
  xen/dt: ifdef out DEV_DT-related bits from device_tree.{c,h}
  xen/dt: Allow CONFIG_DOM0LESS_BOOT to include device-tree/
  kconfig: Allow x86 to pick CONFIG_DOM0LESS_BOOT

 xen/arch/arm/domain_build.c             |   2 +-
 xen/arch/arm/include/asm/grant_table.h  |   1 -
 xen/arch/arm/include/asm/setup.h        |  16 +-
 xen/arch/arm/mmu/mm.c                   |   1 +
 xen/arch/riscv/aplic.c                  |   3 +-
 xen/arch/riscv/include/asm/intc.h       |   2 +
 xen/arch/riscv/mm.c                     |   2 +-
 xen/arch/riscv/setup.c                  |   2 +-
 xen/arch/x86/Kconfig                    |   1 +
 xen/arch/x86/cpu/microcode/core.c       |   9 +-
 xen/arch/x86/dom0_build.c               |   2 +-
 xen/arch/x86/hvm/dom0_build.c           |  16 +-
 xen/arch/x86/include/asm/boot-domain.h  |  33 --
 xen/arch/x86/include/asm/bootfdt.h      |  52 ++
 xen/arch/x86/include/asm/bootinfo.h     |  63 +--
 xen/arch/x86/include/asm/dom0_build.h   |   6 +-
 xen/arch/x86/include/asm/kernel.h       |  20 +
 xen/arch/x86/include/asm/pci.h          |   2 +
 xen/arch/x86/include/asm/setup.h        |  10 +-
 xen/arch/x86/pv/dom0_build.c            |  12 +-
 xen/arch/x86/setup.c                    |  69 +--
 xen/common/Kconfig                      |   9 +-
 xen/common/Makefile                     |   2 +-
 xen/common/device-tree/Makefile         |   9 +-
 xen/common/device-tree/bootfdt.c        | 624 ++----------------------
 xen/common/device-tree/bootinfo-fdt.c   | 554 +++++++++++++++++++++
 xen/common/device-tree/bootinfo.c       |   3 +-
 xen/common/device-tree/device-tree.c    |   2 +
 xen/common/device-tree/dom0less-build.c |   2 +-
 xen/common/device-tree/domain-build.c   |   2 +-
 xen/common/device-tree/kernel.c         |   2 +-
 xen/include/asm-generic/device.h        |  18 +-
 xen/include/xen/bootfdt.h               | 272 +++--------
 xen/include/xen/bootinfo.h              | 212 ++++++++
 xen/include/xen/device_tree.h           |  38 +-
 xen/include/xen/fdt-domain-build.h      |   2 +-
 xen/include/xen/fdt-kernel.h            |   4 +-
 xen/include/xen/grant_table.h           |   2 +-
 xen/include/xen/sched.h                 |   8 +-
 xen/xsm/xsm_policy.c                    |   4 +-
 40 files changed, 1071 insertions(+), 1022 deletions(-)
 delete mode 100644 xen/arch/x86/include/asm/boot-domain.h
 create mode 100644 xen/arch/x86/include/asm/bootfdt.h
 create mode 100644 xen/arch/x86/include/asm/kernel.h
 create mode 100644 xen/common/device-tree/bootinfo-fdt.c
 create mode 100644 xen/include/xen/bootinfo.h

-- 
2.43.0

[PATCH 01/19] licence: Add missing SPDX line to bootfdt.h

[Alejandro Vallejo]

Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
 xen/include/xen/bootfdt.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 80a90e53c0..847f019559 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 #ifndef XEN_BOOTFDT_H
 #define XEN_BOOTFDT_H
 
-- 
2.43.0

Re: [PATCH 01/19] licence: Add missing SPDX line to bootfdt.h

[Orzel, Michal]

On 30/05/2025 14:02, Alejandro Vallejo wrote:
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
> ---
>  xen/include/xen/bootfdt.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index 80a90e53c0..847f019559 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -1,3 +1,4 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
>  #ifndef XEN_BOOTFDT_H
>  #define XEN_BOOTFDT_H
>  

Acked-by: Michal Orzel <michal.orzel@amd.com>

~Michal

[PATCH 02/19] x86: Add missing pci_dev forward declaration in asm/pci.h

[Alejandro Vallejo]

Not a functional change.

Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
 xen/arch/x86/include/asm/pci.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/x86/include/asm/pci.h b/xen/arch/x86/include/asm/pci.h
index bed99437cc..2e67cba8b9 100644
--- a/xen/arch/x86/include/asm/pci.h
+++ b/xen/arch/x86/include/asm/pci.h
@@ -13,6 +13,8 @@
                         || (id) == 0x01128086 || (id) == 0x01228086 \
                         || (id) == 0x010A8086 )
 
+struct pci_dev;
+
 struct arch_pci_dev {
     vmask_t used_vectors;
     /*
-- 
2.43.0

Re: [PATCH 02/19] x86: Add missing pci_dev forward declaration in asm/pci.h

[Jason Andryuk]

On 2025-05-30 08:02, Alejandro Vallejo wrote:
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>

Some sort of reason would be good in the commit message.

"struct pci_dev is used in function prototypes within the header.  This 
is in preparation for including (transitively) in device tree"?

... I'm guessing that is why.  Stating  it would be better.

With a suitable reason:

Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>

Regards,
Jason

Re: [PATCH 02/19] x86: Add missing pci_dev forward declaration in asm/pci.h

[Alejandro Vallejo]

On Fri May 30, 2025 at 11:04 PM CEST, Jason Andryuk wrote:
> On 2025-05-30 08:02, Alejandro Vallejo wrote:
>> Not a functional change.
>> 
>> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
>
> Some sort of reason would be good in the commit message.
>
> "struct pci_dev is used in function prototypes within the header.  This 
> is in preparation for including (transitively) in device tree"?

>
> ... I'm guessing that is why.  Stating  it would be better.

Yes, but I'm not sure the second part of that explanation is relevant. Unless
specifically noted in the header, they are meant to stand by themselves when
possible and not require preinclusion of something else (in this case, xen/pci.h).

This patch would still be relevant (imo) even if I wasn't using the header for
anything.

>
> With a suitable reason:
>
> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>

Thanks,

Does this sound reasonable?

  struct pci_dev is used in function prototypes within the header, so it must
  be forward declared for asm/pci.h not to depend on xen/pci.h being included
  first.

>
> Regards,
> Jason

Cheers,
Alejandro

Re: [PATCH 02/19] x86: Add missing pci_dev forward declaration in asm/pci.h

[Jason Andryuk]

On 2025-06-02 09:45, Alejandro Vallejo wrote:
> On Fri May 30, 2025 at 11:04 PM CEST, Jason Andryuk wrote:
>> On 2025-05-30 08:02, Alejandro Vallejo wrote:
>>> Not a functional change.
>>>
>>> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
>>
>> Some sort of reason would be good in the commit message.
>>
>> "struct pci_dev is used in function prototypes within the header.  This
>> is in preparation for including (transitively) in device tree"?
> 
>>
>> ... I'm guessing that is why.  Stating  it would be better.
> 
> Yes, but I'm not sure the second part of that explanation is relevant. Unless
> specifically noted in the header, they are meant to stand by themselves when
> possible and not require preinclusion of something else (in this case, xen/pci.h).
> 
> This patch would still be relevant (imo) even if I wasn't using the header for
> anything.

Yes, this could be made as a totally independent clean up, and that 
would be fine.  If this is a prerequisite for some later change, I think 
it is useful to highlight it.  It would not otherwise be evident when 
looking at the history.  Because I haven't gotten farther into the 
series, I don't know if this patch is an independent cleanup or a 
prerequisite.

>>
>> With a suitable reason:
>>
>> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
> 
> Thanks,
> 
> Does this sound reasonable?
> 
>    struct pci_dev is used in function prototypes within the header, so it must
>    be forward declared for asm/pci.h not to depend on xen/pci.h being included
>    first.

Sure.  Or just:
struct pci_dev is used in function prototypes within the header, so this 
forward declaration makes it standalone.

My point is: we should explicitly state what the patch is trying to 
achieve.  It helps reviewers and future git history readers.

Regards,
Jason

Re: [PATCH 02/19] x86: Add missing pci_dev forward declaration in asm/pci.h

[Stefano Stabellini]

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

> ---
>  xen/arch/x86/include/asm/pci.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/xen/arch/x86/include/asm/pci.h b/xen/arch/x86/include/asm/pci.h
> index bed99437cc..2e67cba8b9 100644
> --- a/xen/arch/x86/include/asm/pci.h
> +++ b/xen/arch/x86/include/asm/pci.h
> @@ -13,6 +13,8 @@
>                          || (id) == 0x01128086 || (id) == 0x01228086 \
>                          || (id) == 0x010A8086 )
>  
> +struct pci_dev;
> +
>  struct arch_pci_dev {
>      vmask_t used_vectors;
>      /*
> -- 
> 2.43.0
> 
> 

Re: [PATCH 02/19] x86: Add missing pci_dev forward declaration in asm/pci.h

[Jan Beulich]

On 30.05.2025 14:02, Alejandro Vallejo wrote:
> --- a/xen/arch/x86/include/asm/pci.h
> +++ b/xen/arch/x86/include/asm/pci.h
> @@ -13,6 +13,8 @@
>                          || (id) == 0x01128086 || (id) == 0x01228086 \
>                          || (id) == 0x010A8086 )
>  
> +struct pci_dev;
> +
>  struct arch_pci_dev {
>      vmask_t used_vectors;
>      /*

Would it perhaps be better to put this ahead of xen/pci.h's #include, thus
helping all architectures?

Jan

Re: [PATCH 02/19] x86: Add missing pci_dev forward declaration in asm/pci.h

[Alejandro Vallejo]

On Mon Jun 2, 2025 at 9:48 AM CEST, Jan Beulich wrote:
> On 30.05.2025 14:02, Alejandro Vallejo wrote:
>> --- a/xen/arch/x86/include/asm/pci.h
>> +++ b/xen/arch/x86/include/asm/pci.h
>> @@ -13,6 +13,8 @@
>>                          || (id) == 0x01128086 || (id) == 0x01228086 \
>>                          || (id) == 0x010A8086 )
>>  
>> +struct pci_dev;
>> +
>>  struct arch_pci_dev {
>>      vmask_t used_vectors;
>>      /*
>
> Would it perhaps be better to put this ahead of xen/pci.h's #include, thus
> helping all architectures?
>
> Jan

You mean include asm/pci.h from xen/pci.h ? Seeing how arch_pci_dev is here it
must already be transitively included. I could replace all asm/pci.h with xen/
pci.h instead, but this seems strictly better so you can include asm/pci.h when
that's all you need.

Or did you mean something else?

Cheers,
Alejandro

Re: [PATCH 02/19] x86: Add missing pci_dev forward declaration in asm/pci.h

[Jan Beulich]

On 02.06.2025 16:01, Alejandro Vallejo wrote:
> On Mon Jun 2, 2025 at 9:48 AM CEST, Jan Beulich wrote:
>> On 30.05.2025 14:02, Alejandro Vallejo wrote:
>>> --- a/xen/arch/x86/include/asm/pci.h
>>> +++ b/xen/arch/x86/include/asm/pci.h
>>> @@ -13,6 +13,8 @@
>>>                          || (id) == 0x01128086 || (id) == 0x01228086 \
>>>                          || (id) == 0x010A8086 )
>>>  
>>> +struct pci_dev;
>>> +
>>>  struct arch_pci_dev {
>>>      vmask_t used_vectors;
>>>      /*
>>
>> Would it perhaps be better to put this ahead of xen/pci.h's #include, thus
>> helping all architectures?
> 
> You mean include asm/pci.h from xen/pci.h ? Seeing how arch_pci_dev is here it
> must already be transitively included. I could replace all asm/pci.h with xen/
> pci.h instead, but this seems strictly better so you can include asm/pci.h when
> that's all you need.

Hmm, I didn't take into account that asm/pci.h is indeed being included all on
its own in a few places. IOW your patch is fine by me as-is.

Jan

[PATCH 03/19] riscv: Add missing forward declaration to intc.h

[Alejandro Vallejo]

Very much not a functional change

Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
 xen/arch/riscv/include/asm/intc.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index 52ba196d87..81f74736ba 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -8,6 +8,8 @@
 #ifndef ASM__RISCV__INTERRUPT_CONTOLLER_H
 #define ASM__RISCV__INTERRUPT_CONTOLLER_H
 
+struct dt_device_node;
+
 enum intc_version {
     INTC_APLIC,
 };
-- 
2.43.0

Re: [PATCH 03/19] riscv: Add missing forward declaration to intc.h

[Stefano Stabellini]

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> Very much not a functional change
> 
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  xen/arch/riscv/include/asm/intc.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
> index 52ba196d87..81f74736ba 100644
> --- a/xen/arch/riscv/include/asm/intc.h
> +++ b/xen/arch/riscv/include/asm/intc.h
> @@ -8,6 +8,8 @@
>  #ifndef ASM__RISCV__INTERRUPT_CONTOLLER_H
>  #define ASM__RISCV__INTERRUPT_CONTOLLER_H
>  
> +struct dt_device_node;
> +
>  enum intc_version {
>      INTC_APLIC,
>  };
> -- 
> 2.43.0
> 

[PATCH 04/19] xen: Add missing forward declaration to btcpupools_get_domain_pool_id

[Alejandro Vallejo]

And remove the ifdef guard, as it's inconsequential.

Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
 xen/include/xen/sched.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 559d201e0c..b5a6a22c7f 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1291,15 +1291,15 @@ static inline unsigned int btcpupools_get_cpupool_id(unsigned int cpu)
 {
     return 0;
 }
-#ifdef CONFIG_HAS_DEVICE_TREE
+
+struct dt_device_node;
+
 static inline int
 btcpupools_get_domain_pool_id(const struct dt_device_node *node)
 {
     return 0;
 }
-#endif
-
-#endif
+#endif /* !CONFIG_BOOT_TIME_CPUPOOLS */
 
 #endif /* __SCHED_H__ */
 
-- 
2.43.0

Re: [PATCH 04/19] xen: Add missing forward declaration to btcpupools_get_domain_pool_id

[Stefano Stabellini]

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> And remove the ifdef guard, as it's inconsequential.
> 
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
> ---
>  xen/include/xen/sched.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 559d201e0c..b5a6a22c7f 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -1291,15 +1291,15 @@ static inline unsigned int btcpupools_get_cpupool_id(unsigned int cpu)
>  {
>      return 0;
>  }
> -#ifdef CONFIG_HAS_DEVICE_TREE
> +
> +struct dt_device_node;
> +
>  static inline int
>  btcpupools_get_domain_pool_id(const struct dt_device_node *node)
>  {
>      return 0;
>  }
> -#endif
> -
> -#endif
> +#endif /* !CONFIG_BOOT_TIME_CPUPOOLS */

Usually the commend would just be /* CONFIG_BOOT_TIME_CPUPOOLS */
without the !

Other than that:

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


>  #endif /* __SCHED_H__ */
>  
> -- 
> 2.43.0
> 

Re: [PATCH 04/19] xen: Add missing forward declaration to btcpupools_get_domain_pool_id

[Alejandro Vallejo]

On Sat May 31, 2025 at 2:46 AM CEST, Stefano Stabellini wrote:
> On Fri, 30 May 2025, Alejandro Vallejo wrote:
>> And remove the ifdef guard, as it's inconsequential.
>> 
>> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
>> ---
>>  xen/include/xen/sched.h | 8 ++++----
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>> 
>> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
>> index 559d201e0c..b5a6a22c7f 100644
>> --- a/xen/include/xen/sched.h
>> +++ b/xen/include/xen/sched.h
>> @@ -1291,15 +1291,15 @@ static inline unsigned int btcpupools_get_cpupool_id(unsigned int cpu)
>>  {
>>      return 0;
>>  }
>> -#ifdef CONFIG_HAS_DEVICE_TREE
>> +
>> +struct dt_device_node;
>> +
>>  static inline int
>>  btcpupools_get_domain_pool_id(const struct dt_device_node *node)
>>  {
>>      return 0;
>>  }
>> -#endif
>> -
>> -#endif
>> +#endif /* !CONFIG_BOOT_TIME_CPUPOOLS */
>
> Usually the commend would just be /* CONFIG_BOOT_TIME_CPUPOOLS */
> without the !

True, my bad. I think I've seen both styles around (e.g: arm/include/asm/pci.h),
but it's true this one is more prevalent.

>
> Other than that:
>
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

Thanks!

Cheers,
Alejandro

[PATCH 05/19] arm: Remove dependencies with membank(s) definitions from setup.h

[Alejandro Vallejo]

... as they can be forward-declared changing arrays for pointers in the function
declarations.

No functional change.

Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
 xen/arch/arm/include/asm/setup.h | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index 6cf272c160..0f9e531a34 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -3,7 +3,6 @@
 
 #include <public/version.h>
 #include <asm/p2m.h>
-#include <xen/bootfdt.h>
 #include <xen/device_tree.h>
 
 #if defined(CONFIG_MMU)
@@ -14,6 +13,9 @@
 
 #define MAX_FDT_SIZE SZ_2M
 
+struct membank;
+struct membanks;
+
 struct map_range_data
 {
     struct domain *d;
@@ -32,13 +34,13 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
 size_t estimate_efi_size(unsigned int mem_nr_banks);
 
 void acpi_create_efi_system_table(struct domain *d,
-                                  struct membank tbl_add[]);
+                                  struct membank *tbl_add);
 
 void acpi_create_efi_mmap_table(struct domain *d,
                                 const struct membanks *mem,
-                                struct membank tbl_add[]);
+                                struct membank *tbl_add);
 
-int acpi_make_efi_nodes(void *fdt, struct membank tbl_add[]);
+int acpi_make_efi_nodes(void *fdt, struct membank *tbl_add);
 
 void create_dom0(void);
 
-- 
2.43.0

Re: [PATCH 05/19] arm: Remove dependencies with membank(s) definitions from setup.h

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 2845 bytes --]

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> ... as they can be forward-declared changing arrays for pointers in the function
> declarations.
> 
> No functional change.
> 
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
> ---
>  xen/arch/arm/include/asm/setup.h | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
> index 6cf272c160..0f9e531a34 100644
> --- a/xen/arch/arm/include/asm/setup.h
> +++ b/xen/arch/arm/include/asm/setup.h
> @@ -3,7 +3,6 @@
>  
>  #include <public/version.h>
>  #include <asm/p2m.h>
> -#include <xen/bootfdt.h>
>  #include <xen/device_tree.h>

This change breaks the build on ARM:

  CC      xsm/xsm_policy.o
xsm/xsm_policy.c: In function ‘xsm_dt_policy_init’:
xsm/xsm_policy.c:71:30: error: implicit declaration of function ‘boot_module_find_by_kind’ [-Werror=implicit-function-declaration]
   71 |     struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_XSM);
      |                              ^~~~~~~~~~~~~~~~~~~~~~~~
xsm/xsm_policy.c:71:30: error: nested extern declaration of ‘boot_module_find_by_kind’ [-Werror=nested-externs]
xsm/xsm_policy.c:71:55: error: ‘BOOTMOD_XSM’ undeclared (first use in this function)
   71 |     struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_XSM);
      |                                                       ^~~~~~~~~~~
xsm/xsm_policy.c:71:55: note: each undeclared identifier is reported only once for each function it appears in
xsm/xsm_policy.c:74:22: error: dereferencing pointer to incomplete type ‘struct bootmodule’
   74 |     if ( !mod || !mod->size )
      |                      ^~
cc1: all warnings being treated as errors
make[2]: *** [Rules.mk:249: xsm/xsm_policy.o] Error 1
make[1]: *** [build.mk:72: xsm] Error 2
make: *** [Makefile:619: xen] Error 2

The rest looks OK


>  #if defined(CONFIG_MMU)
> @@ -14,6 +13,9 @@
>  
>  #define MAX_FDT_SIZE SZ_2M
>  
> +struct membank;
> +struct membanks;
> +
>  struct map_range_data
>  {
>      struct domain *d;
> @@ -32,13 +34,13 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
>  size_t estimate_efi_size(unsigned int mem_nr_banks);
>  
>  void acpi_create_efi_system_table(struct domain *d,
> -                                  struct membank tbl_add[]);
> +                                  struct membank *tbl_add);
>  
>  void acpi_create_efi_mmap_table(struct domain *d,
>                                  const struct membanks *mem,
> -                                struct membank tbl_add[]);
> +                                struct membank *tbl_add);
>  
> -int acpi_make_efi_nodes(void *fdt, struct membank tbl_add[]);
> +int acpi_make_efi_nodes(void *fdt, struct membank *tbl_add);
>  
>  void create_dom0(void);
>  
> -- 
> 2.43.0
> 

Re: [PATCH 05/19] arm: Remove dependencies with membank(s) definitions from setup.h

[Alejandro Vallejo]

On Sat May 31, 2025 at 2:51 AM CEST, Stefano Stabellini wrote:
> On Fri, 30 May 2025, Alejandro Vallejo wrote:
>> ... as they can be forward-declared changing arrays for pointers in the function
>> declarations.
>> 
>> No functional change.
>> 
>> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
>> ---
>>  xen/arch/arm/include/asm/setup.h | 10 ++++++----
>>  1 file changed, 6 insertions(+), 4 deletions(-)
>> 
>> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
>> index 6cf272c160..0f9e531a34 100644
>> --- a/xen/arch/arm/include/asm/setup.h
>> +++ b/xen/arch/arm/include/asm/setup.h
>> @@ -3,7 +3,6 @@
>>  
>>  #include <public/version.h>
>>  #include <asm/p2m.h>
>> -#include <xen/bootfdt.h>
>>  #include <xen/device_tree.h>
>
> This change breaks the build on ARM:
>
>   CC      xsm/xsm_policy.o
> xsm/xsm_policy.c: In function ‘xsm_dt_policy_init’:
> xsm/xsm_policy.c:71:30: error: implicit declaration of function ‘boot_module_find_by_kind’ [-Werror=implicit-function-declaration]
>    71 |     struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_XSM);
>       |                              ^~~~~~~~~~~~~~~~~~~~~~~~
> xsm/xsm_policy.c:71:30: error: nested extern declaration of ‘boot_module_find_by_kind’ [-Werror=nested-externs]
> xsm/xsm_policy.c:71:55: error: ‘BOOTMOD_XSM’ undeclared (first use in this function)
>    71 |     struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_XSM);
>       |                                                       ^~~~~~~~~~~
> xsm/xsm_policy.c:71:55: note: each undeclared identifier is reported only once for each function it appears in
> xsm/xsm_policy.c:74:22: error: dereferencing pointer to incomplete type ‘struct bootmodule’
>    74 |     if ( !mod || !mod->size )
>       |                      ^~
> cc1: all warnings being treated as errors
> make[2]: *** [Rules.mk:249: xsm/xsm_policy.o] Error 1
> make[1]: *** [build.mk:72: xsm] Error 2
> make: *** [Makefile:619: xen] Error 2
>
> The rest looks OK

Ugh. The series passed regular CI, but it must not have had XSM compiled-in. I'll
sort that out and re-send.

Cheers,
Alejandro

Re: [PATCH 05/19] arm: Remove dependencies with membank(s) definitions from setup.h

[Alejandro Vallejo]

On Sat May 31, 2025 at 2:51 AM CEST, Stefano Stabellini wrote:
> On Fri, 30 May 2025, Alejandro Vallejo wrote:
>> ... as they can be forward-declared changing arrays for pointers in the function
>> declarations.
>> 
>> No functional change.
>> 
>> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
>> ---
>>  xen/arch/arm/include/asm/setup.h | 10 ++++++----
>>  1 file changed, 6 insertions(+), 4 deletions(-)
>> 
>> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
>> index 6cf272c160..0f9e531a34 100644
>> --- a/xen/arch/arm/include/asm/setup.h
>> +++ b/xen/arch/arm/include/asm/setup.h
>> @@ -3,7 +3,6 @@
>>  
>>  #include <public/version.h>
>>  #include <asm/p2m.h>
>> -#include <xen/bootfdt.h>
>>  #include <xen/device_tree.h>
>
> This change breaks the build on ARM:
>
>   CC      xsm/xsm_policy.o
> xsm/xsm_policy.c: In function ‘xsm_dt_policy_init’:
> xsm/xsm_policy.c:71:30: error: implicit declaration of function ‘boot_module_find_by_kind’ [-Werror=implicit-function-declaration]
>    71 |     struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_XSM);
>       |                              ^~~~~~~~~~~~~~~~~~~~~~~~
> xsm/xsm_policy.c:71:30: error: nested extern declaration of ‘boot_module_find_by_kind’ [-Werror=nested-externs]
> xsm/xsm_policy.c:71:55: error: ‘BOOTMOD_XSM’ undeclared (first use in this function)
>    71 |     struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_XSM);
>       |                                                       ^~~~~~~~~~~
> xsm/xsm_policy.c:71:55: note: each undeclared identifier is reported only once for each function it appears in
> xsm/xsm_policy.c:74:22: error: dereferencing pointer to incomplete type ‘struct bootmodule’
>    74 |     if ( !mod || !mod->size )
>       |                      ^~
> cc1: all warnings being treated as errors
> make[2]: *** [Rules.mk:249: xsm/xsm_policy.o] Error 1
> make[1]: *** [build.mk:72: xsm] Error 2
> make: *** [Makefile:619: xen] Error 2
>
> The rest looks OK

I see what goes on now. Later on the header shuffling fixes this breakage (somehow).

This is very much non-essential. I'll drop it for now and have another crack
later on after the patches I do care most about get through.

Cheers,
Alejandro

[PATCH 06/19] xen: Clean up asm-generic/device.h

[Alejandro Vallejo]

There's some pretense this header may be used without
CONFIG_HAS_DEVICE_TREE, but that's just wishful thinking. Only x86 lacks
that option, and it fully overrides this header, typedeffing struct
pci_dev to be device_t.

Furthermore there's an include for xen/device_tree.h halfway through the
header, but that header already includes asm/device.h, creating a cycle.

Clean up the header removing ifdef guards, merging the typedef onto the
struct definition for device_t and removing the spurious include.

The only affected file is aplic.c, in riscv, which is forced now to
include device_tree.h directly.

Not a functional change.

Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
 xen/arch/riscv/aplic.c           |  3 ++-
 xen/include/asm-generic/device.h | 18 ++----------------
 2 files changed, 4 insertions(+), 17 deletions(-)

diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index caba8f8993..90bf222eeb 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -9,12 +9,13 @@
  * Copyright (c) 2024-2025 Vates
  */
 
+#include <xen/device_tree.h>
 #include <xen/errno.h>
 #include <xen/init.h>
+#include <xen/lib.h>
 #include <xen/sections.h>
 #include <xen/types.h>
 
-#include <asm/device.h>
 #include <asm/intc.h>
 
 static struct intc_info __ro_after_init aplic_info = {
diff --git a/xen/include/asm-generic/device.h b/xen/include/asm-generic/device.h
index 1acd1ba1d8..d485fb97dc 100644
--- a/xen/include/asm-generic/device.h
+++ b/xen/include/asm-generic/device.h
@@ -6,9 +6,7 @@
 
 enum device_type
 {
-#ifdef CONFIG_HAS_DEVICE_TREE
     DEV_DT,
-#endif
     DEV_PCI
 };
 
@@ -23,23 +21,15 @@ enum device_class
 };
 
 /* struct device - The basic device structure */
-struct device
+typedef struct device
 {
     enum device_type type;
-#ifdef CONFIG_HAS_DEVICE_TREE
     struct dt_device_node *of_node; /* Used by drivers imported from Linux */
-#endif
 #ifdef CONFIG_HAS_PASSTHROUGH
     void *iommu; /* IOMMU private data */;
     struct iommu_fwspec *iommu_fwspec; /* per-device IOMMU instance data */
 #endif
-};
-
-typedef struct device device_t;
-
-#ifdef CONFIG_HAS_DEVICE_TREE
-
-#include <xen/device_tree.h>
+} device_t;
 
 #define dev_is_dt(dev)  ((dev)->type == DEV_DT)
 
@@ -87,10 +77,6 @@ struct device_desc {
     int (*init)(struct dt_device_node *dev, const void *data);
 };
 
-#else /* !CONFIG_HAS_DEVICE_TREE */
-#define dev_is_dt(dev) ((void)(dev), false)
-#endif /* CONFIG_HAS_DEVICE_TREE */
-
 #define dev_is_pci(dev) ((dev)->type == DEV_PCI)
 
 #ifdef CONFIG_ACPI
-- 
2.43.0

Re: [PATCH 06/19] xen: Clean up asm-generic/device.h

[Stefano Stabellini]

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> There's some pretense this header may be used without
> CONFIG_HAS_DEVICE_TREE, but that's just wishful thinking. Only x86 lacks
> that option, and it fully overrides this header, typedeffing struct
> pci_dev to be device_t.
> 
> Furthermore there's an include for xen/device_tree.h halfway through the
> header, but that header already includes asm/device.h, creating a cycle.
> 
> Clean up the header removing ifdef guards, merging the typedef onto the
> struct definition for device_t and removing the spurious include.
> 
> The only affected file is aplic.c, in riscv, which is forced now to
> include device_tree.h directly.
> 
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  xen/arch/riscv/aplic.c           |  3 ++-
>  xen/include/asm-generic/device.h | 18 ++----------------
>  2 files changed, 4 insertions(+), 17 deletions(-)
> 
> diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
> index caba8f8993..90bf222eeb 100644
> --- a/xen/arch/riscv/aplic.c
> +++ b/xen/arch/riscv/aplic.c
> @@ -9,12 +9,13 @@
>   * Copyright (c) 2024-2025 Vates
>   */
>  
> +#include <xen/device_tree.h>
>  #include <xen/errno.h>
>  #include <xen/init.h>
> +#include <xen/lib.h>
>  #include <xen/sections.h>
>  #include <xen/types.h>
>  
> -#include <asm/device.h>
>  #include <asm/intc.h>
>  
>  static struct intc_info __ro_after_init aplic_info = {
> diff --git a/xen/include/asm-generic/device.h b/xen/include/asm-generic/device.h
> index 1acd1ba1d8..d485fb97dc 100644
> --- a/xen/include/asm-generic/device.h
> +++ b/xen/include/asm-generic/device.h
> @@ -6,9 +6,7 @@
>  
>  enum device_type
>  {
> -#ifdef CONFIG_HAS_DEVICE_TREE
>      DEV_DT,
> -#endif
>      DEV_PCI
>  };
>  
> @@ -23,23 +21,15 @@ enum device_class
>  };
>  
>  /* struct device - The basic device structure */
> -struct device
> +typedef struct device
>  {
>      enum device_type type;
> -#ifdef CONFIG_HAS_DEVICE_TREE
>      struct dt_device_node *of_node; /* Used by drivers imported from Linux */
> -#endif
>  #ifdef CONFIG_HAS_PASSTHROUGH
>      void *iommu; /* IOMMU private data */;
>      struct iommu_fwspec *iommu_fwspec; /* per-device IOMMU instance data */
>  #endif
> -};
> -
> -typedef struct device device_t;
> -
> -#ifdef CONFIG_HAS_DEVICE_TREE
> -
> -#include <xen/device_tree.h>
> +} device_t;
>  
>  #define dev_is_dt(dev)  ((dev)->type == DEV_DT)
>  
> @@ -87,10 +77,6 @@ struct device_desc {
>      int (*init)(struct dt_device_node *dev, const void *data);
>  };
>  
> -#else /* !CONFIG_HAS_DEVICE_TREE */
> -#define dev_is_dt(dev) ((void)(dev), false)
> -#endif /* CONFIG_HAS_DEVICE_TREE */
> -
>  #define dev_is_pci(dev) ((dev)->type == DEV_PCI)
>  
>  #ifdef CONFIG_ACPI
> -- 
> 2.43.0
> 

Re: [PATCH 06/19] xen: Clean up asm-generic/device.h

[Jan Beulich]

On 30.05.2025 14:02, Alejandro Vallejo wrote:
> --- a/xen/include/asm-generic/device.h
> +++ b/xen/include/asm-generic/device.h
> @@ -6,9 +6,7 @@
>  
>  enum device_type
>  {
> -#ifdef CONFIG_HAS_DEVICE_TREE
>      DEV_DT,
> -#endif

Why would this enumerator need exposing on a non-DT arch? In fact I would have
hoped for ...

>      DEV_PCI

... this to be hidden for arch-es not supporting PCI.

Similar concerns elsewhere in this change.

Jan

Re: [PATCH 06/19] xen: Clean up asm-generic/device.h

[Alejandro Vallejo]

On Mon Jun 2, 2025 at 9:51 AM CEST, Jan Beulich wrote:
> On 30.05.2025 14:02, Alejandro Vallejo wrote:
>> --- a/xen/include/asm-generic/device.h
>> +++ b/xen/include/asm-generic/device.h
>> @@ -6,9 +6,7 @@
>>  
>>  enum device_type
>>  {
>> -#ifdef CONFIG_HAS_DEVICE_TREE
>>      DEV_DT,
>> -#endif
>
> Why would this enumerator need exposing on a non-DT arch? In fact I would have
> hoped for ...

A non-DT arch would not include this. x86 doesn't.

>
>>      DEV_PCI
>
> ... this to be hidden for arch-es not supporting PCI.
>
> Similar concerns elsewhere in this change.
>
> Jan

This file is exclusively used by arches supporting DT to abstract away where
the device came from. x86 does not use it at all, and while it wouldn't be
impossible to compile-out DEV_PCI, it would needlessly pollute the codebase with
no measurable gain, because the abstractions still need to stay.

This patch is merely removing ifdefs that don't amount to anything in practice,
and I'd rather not go further than that.

Cheers,
Alejandro

Re: [PATCH 06/19] xen: Clean up asm-generic/device.h

[Jan Beulich]

On 02.06.2025 16:19, Alejandro Vallejo wrote:
> On Mon Jun 2, 2025 at 9:51 AM CEST, Jan Beulich wrote:
>> On 30.05.2025 14:02, Alejandro Vallejo wrote:
>>> --- a/xen/include/asm-generic/device.h
>>> +++ b/xen/include/asm-generic/device.h
>>> @@ -6,9 +6,7 @@
>>>  
>>>  enum device_type
>>>  {
>>> -#ifdef CONFIG_HAS_DEVICE_TREE
>>>      DEV_DT,
>>> -#endif
>>
>> Why would this enumerator need exposing on a non-DT arch? In fact I would have
>> hoped for ...
> 
> A non-DT arch would not include this. x86 doesn't.

Both here and ...

>>>      DEV_PCI
>>
>> ... this to be hidden for arch-es not supporting PCI.
>>
>> Similar concerns elsewhere in this change.
> 
> This file is exclusively used by arches supporting DT to abstract away where
> the device came from. x86 does not use it at all, and while it wouldn't be
> impossible to compile-out DEV_PCI, it would needlessly pollute the codebase with
> no measurable gain, because the abstractions still need to stay.

... here: In "xen/include/asm-generic/device.h" there's nothing at all saying
that this file is a DT-only one. Instead there is something in there saying
that it's suitable to use in the entirely "generic" case.

Jan

Re: [PATCH 06/19] xen: Clean up asm-generic/device.h

[Alejandro Vallejo]

On Mon Jun 2, 2025 at 4:24 PM CEST, Jan Beulich wrote:
> On 02.06.2025 16:19, Alejandro Vallejo wrote:
>> On Mon Jun 2, 2025 at 9:51 AM CEST, Jan Beulich wrote:
>>> On 30.05.2025 14:02, Alejandro Vallejo wrote:
>>>> --- a/xen/include/asm-generic/device.h
>>>> +++ b/xen/include/asm-generic/device.h
>>>> @@ -6,9 +6,7 @@
>>>>  
>>>>  enum device_type
>>>>  {
>>>> -#ifdef CONFIG_HAS_DEVICE_TREE
>>>>      DEV_DT,
>>>> -#endif
>>>
>>> Why would this enumerator need exposing on a non-DT arch? In fact I would have
>>> hoped for ...
>> 
>> A non-DT arch would not include this. x86 doesn't.
>
> Both here and ...
>
>>>>      DEV_PCI
>>>
>>> ... this to be hidden for arch-es not supporting PCI.
>>>
>>> Similar concerns elsewhere in this change.
>> 
>> This file is exclusively used by arches supporting DT to abstract away where
>> the device came from. x86 does not use it at all, and while it wouldn't be
>> impossible to compile-out DEV_PCI, it would needlessly pollute the codebase with
>> no measurable gain, because the abstractions still need to stay.
>
> ... here: In "xen/include/asm-generic/device.h" there's nothing at all saying
> that this file is a DT-only one. Instead there is something in there saying
> that it's suitable to use in the entirely "generic" case.
>
> Jan

Try to use it from x86 and observe the build system catch fire. It could be made
to not go on fire, but it implies heavy refactoring in x86 (particularly IOMMU
code) for no good reason because there's no devices in a DTB to disambiguate.

How about adding this to the top of the header?

```
 /*
  * This header helps DTB-based architectures abstract away where a particular
  * device comes from; be it the DTB itself or enumerated on a PCI bus. 
  */

  [snip]

 #ifndef CONFIG_HAS_DEVICE_TREE
 #error "Header meant to be used exclusively by DTB-base architectures."
 #endif
```

Cheers,
Alejandro

Re: [PATCH 06/19] xen: Clean up asm-generic/device.h

[Jan Beulich]

On 05.06.2025 16:15, Alejandro Vallejo wrote:
> On Mon Jun 2, 2025 at 4:24 PM CEST, Jan Beulich wrote:
>> On 02.06.2025 16:19, Alejandro Vallejo wrote:
>>> On Mon Jun 2, 2025 at 9:51 AM CEST, Jan Beulich wrote:
>>>> On 30.05.2025 14:02, Alejandro Vallejo wrote:
>>>>> --- a/xen/include/asm-generic/device.h
>>>>> +++ b/xen/include/asm-generic/device.h
>>>>> @@ -6,9 +6,7 @@
>>>>>  
>>>>>  enum device_type
>>>>>  {
>>>>> -#ifdef CONFIG_HAS_DEVICE_TREE
>>>>>      DEV_DT,
>>>>> -#endif
>>>>
>>>> Why would this enumerator need exposing on a non-DT arch? In fact I would have
>>>> hoped for ...
>>>
>>> A non-DT arch would not include this. x86 doesn't.
>>
>> Both here and ...
>>
>>>>>      DEV_PCI
>>>>
>>>> ... this to be hidden for arch-es not supporting PCI.
>>>>
>>>> Similar concerns elsewhere in this change.
>>>
>>> This file is exclusively used by arches supporting DT to abstract away where
>>> the device came from. x86 does not use it at all, and while it wouldn't be
>>> impossible to compile-out DEV_PCI, it would needlessly pollute the codebase with
>>> no measurable gain, because the abstractions still need to stay.
>>
>> ... here: In "xen/include/asm-generic/device.h" there's nothing at all saying
>> that this file is a DT-only one. Instead there is something in there saying
>> that it's suitable to use in the entirely "generic" case.
>>
>> Jan
> 
> Try to use it from x86 and observe the build system catch fire. It could be made
> to not go on fire, but it implies heavy refactoring in x86 (particularly IOMMU
> code) for no good reason because there's no devices in a DTB to disambiguate.
> 
> How about adding this to the top of the header?
> 
> ```
>  /*
>   * This header helps DTB-based architectures abstract away where a particular
>   * device comes from; be it the DTB itself or enumerated on a PCI bus. 
>   */
> 
>   [snip]
> 
>  #ifndef CONFIG_HAS_DEVICE_TREE
>  #error "Header meant to be used exclusively by DTB-base architectures."
>  #endif
> ```

Might be fine, together with giving the file a name somewhat referring to DT.

Jan

Re: [PATCH 06/19] xen: Clean up asm-generic/device.h

[Alejandro Vallejo]

On Thu Jun 5, 2025 at 4:20 PM CEST, Jan Beulich wrote:
> On 05.06.2025 16:15, Alejandro Vallejo wrote:
>> On Mon Jun 2, 2025 at 4:24 PM CEST, Jan Beulich wrote:
>>> On 02.06.2025 16:19, Alejandro Vallejo wrote:
>>>> On Mon Jun 2, 2025 at 9:51 AM CEST, Jan Beulich wrote:
>>>>> On 30.05.2025 14:02, Alejandro Vallejo wrote:
>>>>>> --- a/xen/include/asm-generic/device.h
>>>>>> +++ b/xen/include/asm-generic/device.h
>>>>>> @@ -6,9 +6,7 @@
>>>>>>  
>>>>>>  enum device_type
>>>>>>  {
>>>>>> -#ifdef CONFIG_HAS_DEVICE_TREE
>>>>>>      DEV_DT,
>>>>>> -#endif
>>>>>
>>>>> Why would this enumerator need exposing on a non-DT arch? In fact I would have
>>>>> hoped for ...
>>>>
>>>> A non-DT arch would not include this. x86 doesn't.
>>>
>>> Both here and ...
>>>
>>>>>>      DEV_PCI
>>>>>
>>>>> ... this to be hidden for arch-es not supporting PCI.
>>>>>
>>>>> Similar concerns elsewhere in this change.
>>>>
>>>> This file is exclusively used by arches supporting DT to abstract away where
>>>> the device came from. x86 does not use it at all, and while it wouldn't be
>>>> impossible to compile-out DEV_PCI, it would needlessly pollute the codebase with
>>>> no measurable gain, because the abstractions still need to stay.
>>>
>>> ... here: In "xen/include/asm-generic/device.h" there's nothing at all saying
>>> that this file is a DT-only one. Instead there is something in there saying
>>> that it's suitable to use in the entirely "generic" case.
>>>
>>> Jan
>> 
>> Try to use it from x86 and observe the build system catch fire. It could be made
>> to not go on fire, but it implies heavy refactoring in x86 (particularly IOMMU
>> code) for no good reason because there's no devices in a DTB to disambiguate.
>> 
>> How about adding this to the top of the header?
>> 
>> ```
>>  /*
>>   * This header helps DTB-based architectures abstract away where a particular
>>   * device comes from; be it the DTB itself or enumerated on a PCI bus. 
>>   */
>> 
>>   [snip]
>> 
>>  #ifndef CONFIG_HAS_DEVICE_TREE
>>  #error "Header meant to be used exclusively by DTB-base architectures."
>>  #endif
>> ```
>
> Might be fine, together with giving the file a name somewhat referring to DT.
>
> Jan

That would bring it out of sync with x86's asm/device.h. Both of them define
device_t and doing so in differently named headers would just be confusing for
everyone.

Cheers,
Alejandro

Re: [PATCH 06/19] xen: Clean up asm-generic/device.h

[Jan Beulich]

On 05.06.2025 18:48, Alejandro Vallejo wrote:
> On Thu Jun 5, 2025 at 4:20 PM CEST, Jan Beulich wrote:
>> On 05.06.2025 16:15, Alejandro Vallejo wrote:
>>> On Mon Jun 2, 2025 at 4:24 PM CEST, Jan Beulich wrote:
>>>> On 02.06.2025 16:19, Alejandro Vallejo wrote:
>>>>> On Mon Jun 2, 2025 at 9:51 AM CEST, Jan Beulich wrote:
>>>>>> On 30.05.2025 14:02, Alejandro Vallejo wrote:
>>>>>>> --- a/xen/include/asm-generic/device.h
>>>>>>> +++ b/xen/include/asm-generic/device.h
>>>>>>> @@ -6,9 +6,7 @@
>>>>>>>  
>>>>>>>  enum device_type
>>>>>>>  {
>>>>>>> -#ifdef CONFIG_HAS_DEVICE_TREE
>>>>>>>      DEV_DT,
>>>>>>> -#endif
>>>>>>
>>>>>> Why would this enumerator need exposing on a non-DT arch? In fact I would have
>>>>>> hoped for ...
>>>>>
>>>>> A non-DT arch would not include this. x86 doesn't.
>>>>
>>>> Both here and ...
>>>>
>>>>>>>      DEV_PCI
>>>>>>
>>>>>> ... this to be hidden for arch-es not supporting PCI.
>>>>>>
>>>>>> Similar concerns elsewhere in this change.
>>>>>
>>>>> This file is exclusively used by arches supporting DT to abstract away where
>>>>> the device came from. x86 does not use it at all, and while it wouldn't be
>>>>> impossible to compile-out DEV_PCI, it would needlessly pollute the codebase with
>>>>> no measurable gain, because the abstractions still need to stay.
>>>>
>>>> ... here: In "xen/include/asm-generic/device.h" there's nothing at all saying
>>>> that this file is a DT-only one. Instead there is something in there saying
>>>> that it's suitable to use in the entirely "generic" case.
>>>>
>>>> Jan
>>>
>>> Try to use it from x86 and observe the build system catch fire. It could be made
>>> to not go on fire, but it implies heavy refactoring in x86 (particularly IOMMU
>>> code) for no good reason because there's no devices in a DTB to disambiguate.
>>>
>>> How about adding this to the top of the header?
>>>
>>> ```
>>>  /*
>>>   * This header helps DTB-based architectures abstract away where a particular
>>>   * device comes from; be it the DTB itself or enumerated on a PCI bus. 
>>>   */
>>>
>>>   [snip]
>>>
>>>  #ifndef CONFIG_HAS_DEVICE_TREE
>>>  #error "Header meant to be used exclusively by DTB-base architectures."
>>>  #endif
>>> ```
>>
>> Might be fine, together with giving the file a name somewhat referring to DT.
> 
> That would bring it out of sync with x86's asm/device.h. Both of them define
> device_t and doing so in differently named headers would just be confusing for
> everyone.

Okay, then the name can't change. In which case the #ifdef-ary needs to remain,
imo, to keep the header being "generic".

Jan

[PATCH 07/19] arm/gnttab: Break cycle between asm/grant_table.h and xen/grant_table.h

[Alejandro Vallejo]

xen/grant_table is meant to pull asm/grant_table, when it exists.

Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
 xen/arch/arm/domain_build.c            | 1 -
 xen/arch/arm/include/asm/grant_table.h | 1 -
 xen/include/xen/grant_table.h          | 2 +-
 3 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b189a7cfae..11cc03e5db 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -37,7 +37,6 @@
 
 #include <xen/irq.h>
 #include <xen/grant_table.h>
-#include <asm/grant_table.h>
 #include <xen/serial.h>
 
 static unsigned int __initdata opt_dom0_max_vcpus;
diff --git a/xen/arch/arm/include/asm/grant_table.h b/xen/arch/arm/include/asm/grant_table.h
index c5d87b60c4..c47058a3a0 100644
--- a/xen/arch/arm/include/asm/grant_table.h
+++ b/xen/arch/arm/include/asm/grant_table.h
@@ -1,7 +1,6 @@
 #ifndef __ASM_GRANT_TABLE_H__
 #define __ASM_GRANT_TABLE_H__
 
-#include <xen/grant_table.h>
 #include <xen/kernel.h>
 #include <xen/pfn.h>
 #include <xen/sched.h>
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index 297d7669e9..491cd6c539 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -27,7 +27,7 @@
 #include <xen/rwlock.h>
 #include <public/grant_table.h>
 
-#ifdef CONFIG_GRANT_TABLE
+#if __has_include("asm/grant_table.h")
 #include <asm/grant_table.h>
 #endif
 
-- 
2.43.0

Re: [PATCH 07/19] arm/gnttab: Break cycle between asm/grant_table.h and xen/grant_table.h

[Jason Andryuk]

On 2025-05-30 08:02, Alejandro Vallejo wrote:
> xen/grant_table is meant to pull asm/grant_table, when it exists.
> 
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>

I think you can also remove this one:
xen/arch/arm/dom0less-build.c:#include <asm/grant_table.h>

With that,
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>

Regards,
Jason

Re: [PATCH 07/19] arm/gnttab: Break cycle between asm/grant_table.h and xen/grant_table.h

[Stefano Stabellini]

On Fri, 30 May 2025, Jason Andryuk wrote:
> On 2025-05-30 08:02, Alejandro Vallejo wrote:
> > xen/grant_table is meant to pull asm/grant_table, when it exists.
> > 
> > Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
> 
> I think you can also remove this one:
> xen/arch/arm/dom0less-build.c:#include <asm/grant_table.h>
> 
> With that,
> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>


Acked-by: Stefano Stabellini <sstabellini@kernel.org>

Re: [PATCH 07/19] arm/gnttab: Break cycle between asm/grant_table.h and xen/grant_table.h

[Alejandro Vallejo]

On Fri May 30, 2025 at 11:04 PM CEST, Jason Andryuk wrote:
> On 2025-05-30 08:02, Alejandro Vallejo wrote:
>> xen/grant_table is meant to pull asm/grant_table, when it exists.
>> 
>> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
>
> I think you can also remove this one:
> xen/arch/arm/dom0less-build.c:#include <asm/grant_table.h>
>
> With that,
> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>

Oh, yes. I missed that one. Thanks.

Cheers,
Alejandro

Re: [PATCH 07/19] arm/gnttab: Break cycle between asm/grant_table.h and xen/grant_table.h

[Jan Beulich]

On 30.05.2025 14:02, Alejandro Vallejo wrote:> --- a/xen/include/xen/grant_table.h
> +++ b/xen/include/xen/grant_table.h
> @@ -27,7 +27,7 @@
>  #include <xen/rwlock.h>
>  #include <public/grant_table.h>
>  
> -#ifdef CONFIG_GRANT_TABLE
> +#if __has_include("asm/grant_table.h")
>  #include <asm/grant_table.h>
>  #endif

This change looks wrong (or otherwise is lacking justification): With GRANT_TABLE=n
the arch header isn't supposed to be included.

Jan

Re: [PATCH 07/19] arm/gnttab: Break cycle between asm/grant_table.h and xen/grant_table.h

[Alejandro Vallejo]

On Mon Jun 2, 2025 at 9:53 AM CEST, Jan Beulich wrote:
> On 30.05.2025 14:02, Alejandro Vallejo wrote:> --- a/xen/include/xen/grant_table.h
>> +++ b/xen/include/xen/grant_table.h
>> @@ -27,7 +27,7 @@
>>  #include <xen/rwlock.h>
>>  #include <public/grant_table.h>
>>  
>> -#ifdef CONFIG_GRANT_TABLE
>> +#if __has_include("asm/grant_table.h")
>>  #include <asm/grant_table.h>
>>  #endif
>
> This change looks wrong (or otherwise is lacking justification): With GRANT_TABLE=n
> the arch header isn't supposed to be included.
>
> Jan

It's not equivalent to the previous code; but that's a feature, not a bug.

Not including the header with GRANT_TABLE=n  was the best we could with
the older toolchains in order to not try to include a header that might not
exist. The high number of sequential inclusions of xen/grant_table.h and
asm/grant_table.h seem to attest to that.

I can ammend the commit message to be clearer, but IMO this is what it was always
meant to be. I can replace the current commit message with:

  "The previous toolchain base version didn't provide __has_include(), which
   allows conditional inclusion based on a header's existence. Lacking that
   feature the inclusion was guarded by the GRANT_TABLE option being present
   but even then sometimes the arch-specific header is required even when
   the option is not selected. This causes inclusion sites to needlessly
   include both asm/grant_table.h and xen/grant_table.h.

   Using __has_include() removes this requirement at inclusion sites."

Thoughts?

Cheers,
Alejandro

Re: [PATCH 07/19] arm/gnttab: Break cycle between asm/grant_table.h and xen/grant_table.h

[Jan Beulich]

On 02.06.2025 16:30, Alejandro Vallejo wrote:
> On Mon Jun 2, 2025 at 9:53 AM CEST, Jan Beulich wrote:
>> On 30.05.2025 14:02, Alejandro Vallejo wrote:> --- a/xen/include/xen/grant_table.h
>>> +++ b/xen/include/xen/grant_table.h
>>> @@ -27,7 +27,7 @@
>>>  #include <xen/rwlock.h>
>>>  #include <public/grant_table.h>
>>>  
>>> -#ifdef CONFIG_GRANT_TABLE
>>> +#if __has_include("asm/grant_table.h")
>>>  #include <asm/grant_table.h>
>>>  #endif
>>
>> This change looks wrong (or otherwise is lacking justification): With GRANT_TABLE=n
>> the arch header isn't supposed to be included.
> 
> It's not equivalent to the previous code; but that's a feature, not a bug.
> 
> Not including the header with GRANT_TABLE=n  was the best we could with
> the older toolchains in order to not try to include a header that might not
> exist. The high number of sequential inclusions of xen/grant_table.h and
> asm/grant_table.h seem to attest to that.
> 
> I can ammend the commit message to be clearer, but IMO this is what it was always
> meant to be. I can replace the current commit message with:
> 
>   "The previous toolchain base version didn't provide __has_include(), which
>    allows conditional inclusion based on a header's existence. Lacking that
>    feature the inclusion was guarded by the GRANT_TABLE option being present
>    but even then sometimes the arch-specific header is required even when
>    the option is not selected. This causes inclusion sites to needlessly
>    include both asm/grant_table.h and xen/grant_table.h.
> 
>    Using __has_include() removes this requirement at inclusion sites."
> 
> Thoughts?

So why would we include a header we don't need when GRANT_TABLE=n? Overall
we're trying to reduce dependency trees rather than growing them further.

Jan

Re: [PATCH 07/19] arm/gnttab: Break cycle between asm/grant_table.h and xen/grant_table.h

[Alejandro Vallejo]

On Mon Jun 2, 2025 at 4:51 PM CEST, Jan Beulich wrote:
> On 02.06.2025 16:30, Alejandro Vallejo wrote:
>> On Mon Jun 2, 2025 at 9:53 AM CEST, Jan Beulich wrote:
>>> On 30.05.2025 14:02, Alejandro Vallejo wrote:> --- a/xen/include/xen/grant_table.h
>>>> +++ b/xen/include/xen/grant_table.h
>>>> @@ -27,7 +27,7 @@
>>>>  #include <xen/rwlock.h>
>>>>  #include <public/grant_table.h>
>>>>  
>>>> -#ifdef CONFIG_GRANT_TABLE
>>>> +#if __has_include("asm/grant_table.h")
>>>>  #include <asm/grant_table.h>
>>>>  #endif
>>>
>>> This change looks wrong (or otherwise is lacking justification): With GRANT_TABLE=n
>>> the arch header isn't supposed to be included.
>> 
>> It's not equivalent to the previous code; but that's a feature, not a bug.
>> 
>> Not including the header with GRANT_TABLE=n  was the best we could with
>> the older toolchains in order to not try to include a header that might not
>> exist. The high number of sequential inclusions of xen/grant_table.h and
>> asm/grant_table.h seem to attest to that.
>> 
>> I can ammend the commit message to be clearer, but IMO this is what it was always
>> meant to be. I can replace the current commit message with:
>> 
>>   "The previous toolchain base version didn't provide __has_include(), which
>>    allows conditional inclusion based on a header's existence. Lacking that
>>    feature the inclusion was guarded by the GRANT_TABLE option being present
>>    but even then sometimes the arch-specific header is required even when
>>    the option is not selected. This causes inclusion sites to needlessly
>>    include both asm/grant_table.h and xen/grant_table.h.
>> 
>>    Using __has_include() removes this requirement at inclusion sites."
>> 
>> Thoughts?
>
> So why would we include a header we don't need when GRANT_TABLE=n? Overall
> we're trying to reduce dependency trees rather than growing them further.
>
> Jan

Because we do need it or the code doesn't compile. gnttab_dom0_frames(), for
instance, exists and is used in unguarded statements. There's more case like
that. It may be possible to break those dependencies so the inclusion is
not always expected, but the reality is that you tend to need the other header
for pretty much the same class of reasons you needed xen/grant_table.h to begin
with.

Forcing the code to include both seems counter-productive to me.

Cheers,
Alejandro

Re: [PATCH 07/19] arm/gnttab: Break cycle between asm/grant_table.h and xen/grant_table.h

[Jan Beulich]

On 02.06.2025 18:39, Alejandro Vallejo wrote:
> On Mon Jun 2, 2025 at 4:51 PM CEST, Jan Beulich wrote:
>> On 02.06.2025 16:30, Alejandro Vallejo wrote:
>>> On Mon Jun 2, 2025 at 9:53 AM CEST, Jan Beulich wrote:
>>>> On 30.05.2025 14:02, Alejandro Vallejo wrote:> --- a/xen/include/xen/grant_table.h
>>>>> +++ b/xen/include/xen/grant_table.h
>>>>> @@ -27,7 +27,7 @@
>>>>>  #include <xen/rwlock.h>
>>>>>  #include <public/grant_table.h>
>>>>>  
>>>>> -#ifdef CONFIG_GRANT_TABLE
>>>>> +#if __has_include("asm/grant_table.h")
>>>>>  #include <asm/grant_table.h>
>>>>>  #endif
>>>>
>>>> This change looks wrong (or otherwise is lacking justification): With GRANT_TABLE=n
>>>> the arch header isn't supposed to be included.
>>>
>>> It's not equivalent to the previous code; but that's a feature, not a bug.
>>>
>>> Not including the header with GRANT_TABLE=n  was the best we could with
>>> the older toolchains in order to not try to include a header that might not
>>> exist. The high number of sequential inclusions of xen/grant_table.h and
>>> asm/grant_table.h seem to attest to that.
>>>
>>> I can ammend the commit message to be clearer, but IMO this is what it was always
>>> meant to be. I can replace the current commit message with:
>>>
>>>   "The previous toolchain base version didn't provide __has_include(), which
>>>    allows conditional inclusion based on a header's existence. Lacking that
>>>    feature the inclusion was guarded by the GRANT_TABLE option being present
>>>    but even then sometimes the arch-specific header is required even when
>>>    the option is not selected. This causes inclusion sites to needlessly
>>>    include both asm/grant_table.h and xen/grant_table.h.
>>>
>>>    Using __has_include() removes this requirement at inclusion sites."
>>>
>>> Thoughts?
>>
>> So why would we include a header we don't need when GRANT_TABLE=n? Overall
>> we're trying to reduce dependency trees rather than growing them further.
> 
> Because we do need it or the code doesn't compile. gnttab_dom0_frames(), for
> instance, exists and is used in unguarded statements.

I fear I don't understand this: Things are building fine right now, aren't
they?

> There's more case like
> that. It may be possible to break those dependencies so the inclusion is
> not always expected, but the reality is that you tend to need the other header
> for pretty much the same class of reasons you needed xen/grant_table.h to begin
> with.
> 
> Forcing the code to include both seems counter-productive to me.

Depends on how frequent the double inclusion is, imo.

Jan

Re: [PATCH 07/19] arm/gnttab: Break cycle between asm/grant_table.h and xen/grant_table.h

[Alejandro Vallejo]

On Tue Jun 3, 2025 at 9:04 AM CEST, Jan Beulich wrote:
> On 02.06.2025 18:39, Alejandro Vallejo wrote:
>> On Mon Jun 2, 2025 at 4:51 PM CEST, Jan Beulich wrote:
>>> On 02.06.2025 16:30, Alejandro Vallejo wrote:
>>>> On Mon Jun 2, 2025 at 9:53 AM CEST, Jan Beulich wrote:
>>>>> On 30.05.2025 14:02, Alejandro Vallejo wrote:> --- a/xen/include/xen/grant_table.h
>>>>>> +++ b/xen/include/xen/grant_table.h
>>>>>> @@ -27,7 +27,7 @@
>>>>>>  #include <xen/rwlock.h>
>>>>>>  #include <public/grant_table.h>
>>>>>>  
>>>>>> -#ifdef CONFIG_GRANT_TABLE
>>>>>> +#if __has_include("asm/grant_table.h")
>>>>>>  #include <asm/grant_table.h>
>>>>>>  #endif
>>>>>
>>>>> This change looks wrong (or otherwise is lacking justification): With GRANT_TABLE=n
>>>>> the arch header isn't supposed to be included.
>>>>
>>>> It's not equivalent to the previous code; but that's a feature, not a bug.
>>>>
>>>> Not including the header with GRANT_TABLE=n  was the best we could with
>>>> the older toolchains in order to not try to include a header that might not
>>>> exist. The high number of sequential inclusions of xen/grant_table.h and
>>>> asm/grant_table.h seem to attest to that.
>>>>
>>>> I can ammend the commit message to be clearer, but IMO this is what it was always
>>>> meant to be. I can replace the current commit message with:
>>>>
>>>>   "The previous toolchain base version didn't provide __has_include(), which
>>>>    allows conditional inclusion based on a header's existence. Lacking that
>>>>    feature the inclusion was guarded by the GRANT_TABLE option being present
>>>>    but even then sometimes the arch-specific header is required even when
>>>>    the option is not selected. This causes inclusion sites to needlessly
>>>>    include both asm/grant_table.h and xen/grant_table.h.
>>>>
>>>>    Using __has_include() removes this requirement at inclusion sites."
>>>>
>>>> Thoughts?
>>>
>>> So why would we include a header we don't need when GRANT_TABLE=n? Overall
>>> we're trying to reduce dependency trees rather than growing them further.
>> 
>> Because we do need it or the code doesn't compile. gnttab_dom0_frames(), for
>> instance, exists and is used in unguarded statements.
>
> I fear I don't understand this: Things are building fine right now, aren't
> they?
>
>> There's more case like
>> that. It may be possible to break those dependencies so the inclusion is
>> not always expected, but the reality is that you tend to need the other header
>> for pretty much the same class of reasons you needed xen/grant_table.h to begin
>> with.
>> 
>> Forcing the code to include both seems counter-productive to me.
>
> Depends on how frequent the double inclusion is, imo.
>
> Jan

Not as much as I feared. I've removed both linkages for v2.

Cheers,
Alejandro

[PATCH 08/19] xen/dt: Add BOOTMOD_MICROCODE

[Alejandro Vallejo]

In preparation for x86 to start using bootmodule instead of boot_module

Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
 xen/common/device-tree/bootinfo.c | 1 +
 xen/include/xen/bootfdt.h         | 1 +
 2 files changed, 2 insertions(+)

diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c
index 76d652c0de..717cfa0962 100644
--- a/xen/common/device-tree/bootinfo.c
+++ b/xen/common/device-tree/bootinfo.c
@@ -31,6 +31,7 @@ const char * __init boot_module_kind_as_string(bootmodule_kind kind)
     case BOOTMOD_RAMDISK: return "Ramdisk";
     case BOOTMOD_XSM:     return "XSM";
     case BOOTMOD_GUEST_DTB:     return "DTB";
+    case BOOTMOD_MICROCODE:     return "Microcode";
     case BOOTMOD_UNKNOWN: return "Unknown";
     default: BUG();
     }
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 847f019559..d503d1bd4b 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -21,6 +21,7 @@ typedef enum {
     BOOTMOD_RAMDISK,
     BOOTMOD_XSM,
     BOOTMOD_GUEST_DTB,
+    BOOTMOD_MICROCODE,
     BOOTMOD_UNKNOWN
 }  bootmodule_kind;
 
-- 
2.43.0

Re: [PATCH 08/19] xen/dt: Add BOOTMOD_MICROCODE

[Stefano Stabellini]

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> In preparation for x86 to start using bootmodule instead of boot_module
> 
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  xen/common/device-tree/bootinfo.c | 1 +
>  xen/include/xen/bootfdt.h         | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c
> index 76d652c0de..717cfa0962 100644
> --- a/xen/common/device-tree/bootinfo.c
> +++ b/xen/common/device-tree/bootinfo.c
> @@ -31,6 +31,7 @@ const char * __init boot_module_kind_as_string(bootmodule_kind kind)
>      case BOOTMOD_RAMDISK: return "Ramdisk";
>      case BOOTMOD_XSM:     return "XSM";
>      case BOOTMOD_GUEST_DTB:     return "DTB";
> +    case BOOTMOD_MICROCODE:     return "Microcode";
>      case BOOTMOD_UNKNOWN: return "Unknown";
>      default: BUG();
>      }
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index 847f019559..d503d1bd4b 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -21,6 +21,7 @@ typedef enum {
>      BOOTMOD_RAMDISK,
>      BOOTMOD_XSM,
>      BOOTMOD_GUEST_DTB,
> +    BOOTMOD_MICROCODE,
>      BOOTMOD_UNKNOWN
>  }  bootmodule_kind;
>  
> -- 
> 2.43.0
> 

Re: [PATCH 08/19] xen/dt: Add BOOTMOD_MICROCODE

[Alejandro Vallejo]

On Sat May 31, 2025 at 2:59 AM CEST, Stefano Stabellini wrote:
> On Fri, 30 May 2025, Alejandro Vallejo wrote:
>> In preparation for x86 to start using bootmodule instead of boot_module
>> 
>> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
>
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

Thanks.

Note to self though, I should be probing for "multiboot,microcode" in the
early scan path now that this new variant is here, to identify the kind of
the blob.

Will do it for v2.

Cheers,
Alejandro

[PATCH 09/19] x86: Preinitialise all modules to be of kind BOOTMOD_UNKNOWN

[Alejandro Vallejo]

A later patch removes boot_module and replaces its uses with bootmodule.
The equivalent field for "type" doesn't have BOOTMOD_UNKNOWN as a zero
value, so it must be explicitly set in the static xen_boot_info.

Not a functional change.

Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
 xen/arch/x86/setup.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 1f5cb67bd0..5da9df33c9 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -298,6 +298,7 @@ struct boot_info __initdata xen_boot_info = {
     .loader = "unknown",
     .cmdline = "",
     .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } },
+    .mods = { [0 ... MAX_NR_BOOTMODS] = { .type = BOOTMOD_UNKNOWN } },
 };
 
 static struct boot_info *__init multiboot_fill_boot_info(
-- 
2.43.0

Re: [PATCH 09/19] x86: Preinitialise all modules to be of kind BOOTMOD_UNKNOWN

[Stefano Stabellini]

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> A later patch removes boot_module and replaces its uses with bootmodule.
> The equivalent field for "type" doesn't have BOOTMOD_UNKNOWN as a zero
> value, so it must be explicitly set in the static xen_boot_info.
> 
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  xen/arch/x86/setup.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 1f5cb67bd0..5da9df33c9 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -298,6 +298,7 @@ struct boot_info __initdata xen_boot_info = {
>      .loader = "unknown",
>      .cmdline = "",
>      .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } },
> +    .mods = { [0 ... MAX_NR_BOOTMODS] = { .type = BOOTMOD_UNKNOWN } },
>  };
>  
>  static struct boot_info *__init multiboot_fill_boot_info(
> -- 
> 2.43.0
> 
> 

Re: [PATCH 09/19] x86: Preinitialise all modules to be of kind BOOTMOD_UNKNOWN

[Jan Beulich]

On 30.05.2025 14:02, Alejandro Vallejo wrote:
> A later patch removes boot_module and replaces its uses with bootmodule.
> The equivalent field for "type" doesn't have BOOTMOD_UNKNOWN as a zero
> value, so it must be explicitly set in the static xen_boot_info.
> 
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
> ---
>  xen/arch/x86/setup.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 1f5cb67bd0..5da9df33c9 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -298,6 +298,7 @@ struct boot_info __initdata xen_boot_info = {
>      .loader = "unknown",
>      .cmdline = "",
>      .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } },
> +    .mods = { [0 ... MAX_NR_BOOTMODS] = { .type = BOOTMOD_UNKNOWN } },
>  };

A brief comment may be nice, to help readers understand that there is no off-
by-1 here.

Jan

Re: [PATCH 09/19] x86: Preinitialise all modules to be of kind BOOTMOD_UNKNOWN

[Alejandro Vallejo]

On Mon Jun 2, 2025 at 9:55 AM CEST, Jan Beulich wrote:
> On 30.05.2025 14:02, Alejandro Vallejo wrote:
>> A later patch removes boot_module and replaces its uses with bootmodule.
>> The equivalent field for "type" doesn't have BOOTMOD_UNKNOWN as a zero
>> value, so it must be explicitly set in the static xen_boot_info.
>> 
>> Not a functional change.
>> 
>> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
>> ---
>>  xen/arch/x86/setup.c | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>> index 1f5cb67bd0..5da9df33c9 100644
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -298,6 +298,7 @@ struct boot_info __initdata xen_boot_info = {
>>      .loader = "unknown",
>>      .cmdline = "",
>>      .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } },
>> +    .mods = { [0 ... MAX_NR_BOOTMODS] = { .type = BOOTMOD_UNKNOWN } },
>>  };
>
> A brief comment may be nice, to help readers understand that there is no off-
> by-1 here.
>
> Jan

Sure.

Cheers,
Alejandro

[PATCH 10/19] x86: Replace boot_module with bootmodule

[Alejandro Vallejo]

These types resemble each other very closely in layout and intent, and
with "struct bootmodule" already in common code it makes perfect sense
to merge them. In order to do so, add an arch-specific area for
x86-specific tidbits.

Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
 xen/arch/x86/cpu/microcode/core.c      |  9 ++--
 xen/arch/x86/hvm/dom0_build.c          | 10 ++---
 xen/arch/x86/include/asm/boot-domain.h |  4 +-
 xen/arch/x86/include/asm/bootfdt.h     | 52 +++++++++++++++++++++++
 xen/arch/x86/include/asm/bootinfo.h    | 58 +++-----------------------
 xen/arch/x86/include/asm/setup.h       |  6 +--
 xen/arch/x86/pv/dom0_build.c           |  8 ++--
 xen/arch/x86/setup.c                   | 52 ++++++++++++-----------
 xen/include/xen/bootfdt.h              |  9 ++++
 xen/xsm/xsm_policy.c                   |  4 +-
 10 files changed, 113 insertions(+), 99 deletions(-)
 create mode 100644 xen/arch/x86/include/asm/bootfdt.h

diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c
index 34a94cd25b..0111ef9156 100644
--- a/xen/arch/x86/cpu/microcode/core.c
+++ b/xen/arch/x86/cpu/microcode/core.c
@@ -760,12 +760,11 @@ static int __init early_microcode_load(struct boot_info *bi)
     {
         for ( idx = 0; idx < bi->nr_modules; ++idx )
         {
-            const struct boot_module *bm = &bi->mods[idx];
+            const struct bootmodule *bm = &bi->mods[idx];
             struct cpio_data cd;
 
             /* Search anything unclaimed or likely to be a CPIO archive. */
-            if ( bm->type != BOOTMOD_UNKNOWN &&
-                 bm->type != BOOTMOD_RAMDISK )
+            if ( bm->kind != BOOTMOD_UNKNOWN && bm->kind != BOOTMOD_RAMDISK )
                 continue;
 
             size = bm->size;
@@ -815,12 +814,12 @@ static int __init early_microcode_load(struct boot_info *bi)
             return -ENODEV;
         }
 
-        if ( bi->mods[idx].type != BOOTMOD_UNKNOWN )
+        if ( bi->mods[idx].kind != BOOTMOD_UNKNOWN )
         {
             printk(XENLOG_WARNING "Microcode: Chosen module %d already used\n", idx);
             return -ENODEV;
         }
-        bi->mods[idx].type = BOOTMOD_MICROCODE;
+        bi->mods[idx].kind = BOOTMOD_MICROCODE;
 
         size = bi->mods[idx].size;
         data = bootstrap_map_bm(&bi->mods[idx]);
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index a038e58c11..96410344a8 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -647,10 +647,10 @@ static int __init pvh_load_kernel(
     const struct boot_domain *bd, paddr_t *entry, paddr_t *start_info_addr)
 {
     struct domain *d = bd->d;
-    struct boot_module *image = bd->kernel;
-    struct boot_module *initrd = bd->module;
+    struct bootmodule *image = bd->kernel;
+    struct bootmodule *initrd = bd->module;
     void *image_base = bootstrap_map_bm(image);
-    void *image_start = image_base + image->headroom;
+    void *image_start = image_base + image->arch.headroom;
     unsigned long image_len = image->size;
     unsigned long initrd_len = initrd ? initrd->size : 0;
     size_t cmdline_len = bd->cmdline ? strlen(bd->cmdline) + 1 : 0;
@@ -721,9 +721,9 @@ static int __init pvh_load_kernel(
     {
         size_t initrd_space = elf_round_up(&elf, initrd_len);
 
-        if ( initrd->cmdline_pa )
+        if ( initrd->arch.cmdline_pa )
         {
-            initrd_cmdline = __va(initrd->cmdline_pa);
+            initrd_cmdline = __va(initrd->arch.cmdline_pa);
             if ( !*initrd_cmdline )
                 initrd_cmdline = NULL;
         }
diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
index d7c6042e25..242e9c9c2b 100644
--- a/xen/arch/x86/include/asm/boot-domain.h
+++ b/xen/arch/x86/include/asm/boot-domain.h
@@ -13,8 +13,8 @@
 struct boot_domain {
     domid_t domid;
 
-    struct boot_module *kernel;
-    struct boot_module *module;
+    struct bootmodule *kernel;
+    struct bootmodule *module;
     const char *cmdline;
 
     struct domain *d;
diff --git a/xen/arch/x86/include/asm/bootfdt.h b/xen/arch/x86/include/asm/bootfdt.h
new file mode 100644
index 0000000000..c00de8c09b
--- /dev/null
+++ b/xen/arch/x86/include/asm/bootfdt.h
@@ -0,0 +1,52 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ARCH_X86_BOOTFDT_H__
+#define __ARCH_X86_BOOTFDT_H__
+
+#include <xen/types.h>
+
+struct arch_bootmodule
+{
+    /*
+     * Module State Flags:
+     *   relocated:   indicates module has been relocated in memory.
+     *   released:    indicates module's pages have been freed.
+     *   fdt_cmdline: indicates module's cmdline is in the FDT.
+     */
+    bool relocated:1;
+    bool released:1;
+    bool fdt_cmdline:1;
+
+    /*
+     * A boot module may need decompressing by Xen.  Headroom is an estimate of
+     * the additional space required to decompress the module.
+     *
+     * Headroom is accounted for at the start of the module.  Decompressing is
+     * done in-place with input=start, output=start-headroom, expecting the
+     * pointers to become equal (give or take some rounding) when decompression
+     * is complete.
+     *
+     * Memory layout at boot:
+     *
+     *               start ----+
+     *                         v
+     *   |<-----headroom------>|<------size------->|
+     *                         +-------------------+
+     *                         | Compressed Module |
+     *   +---------------------+-------------------+
+     *   |           Decompressed Module           |
+     *   +-----------------------------------------+
+     */
+    unsigned long headroom;
+    paddr_t cmdline_pa;
+};
+
+#endif /* __ARCH_X86_BOOTFDT_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
index 3afc214c17..f3210b7d6a 100644
--- a/xen/arch/x86/include/asm/bootinfo.h
+++ b/xen/arch/x86/include/asm/bootinfo.h
@@ -8,6 +8,7 @@
 #ifndef X86_BOOTINFO_H
 #define X86_BOOTINFO_H
 
+#include <xen/bootfdt.h>
 #include <xen/init.h>
 #include <xen/multiboot.h>
 #include <xen/types.h>
@@ -19,55 +20,6 @@
 /* Max number of boot domains that Xen can construct */
 #define MAX_NR_BOOTDOMS 1
 
-/* Boot module binary type / purpose */
-enum bootmod_type {
-    BOOTMOD_UNKNOWN,
-    BOOTMOD_XEN,
-    BOOTMOD_KERNEL,
-    BOOTMOD_RAMDISK,
-    BOOTMOD_MICROCODE,
-    BOOTMOD_XSM_POLICY,
-};
-
-struct boot_module {
-    enum bootmod_type type;
-
-    /*
-     * Module State Flags:
-     *   relocated: indicates module has been relocated in memory.
-     *   released:  indicates module's pages have been freed.
-     */
-    bool relocated:1;
-    bool released:1;
-
-    /*
-     * A boot module may need decompressing by Xen.  Headroom is an estimate of
-     * the additional space required to decompress the module.
-     *
-     * Headroom is accounted for at the start of the module.  Decompressing is
-     * done in-place with input=start, output=start-headroom, expecting the
-     * pointers to become equal (give or take some rounding) when decompression
-     * is complete.
-     *
-     * Memory layout at boot:
-     *
-     *               start ----+
-     *                         v
-     *   |<-----headroom------>|<------size------->|
-     *                         +-------------------+
-     *                         | Compressed Module |
-     *   +---------------------+-------------------+
-     *   |           Decompressed Module           |
-     *   +-----------------------------------------+
-     */
-    unsigned long headroom;
-
-    paddr_t cmdline_pa;
-
-    paddr_t start;
-    size_t size;
-};
-
 /*
  * Xen internal representation of information provided by the
  * bootloader/environment, or derived from the information.
@@ -81,7 +33,7 @@ struct boot_info {
     size_t memmap_length;
 
     unsigned int nr_modules;
-    struct boot_module mods[MAX_NR_BOOTMODS + 1];
+    struct bootmodule mods[MAX_NR_BOOTMODS + 1];
     struct boot_domain domains[MAX_NR_BOOTDOMS];
 };
 
@@ -94,16 +46,16 @@ struct boot_info {
  *      Failure - a value greater than MAX_NR_BOOTMODS
  */
 static inline unsigned int __init next_boot_module_index(
-    const struct boot_info *bi, enum bootmod_type t, unsigned int start)
+    const struct boot_info *bi, bootmodule_kind k, unsigned int start)
 {
     unsigned int i;
 
-    if ( t == BOOTMOD_XEN )
+    if ( k == BOOTMOD_XEN )
         return bi->nr_modules;
 
     for ( i = start; i < bi->nr_modules; i++ )
     {
-        if ( bi->mods[i].type == t )
+        if ( bi->mods[i].kind == k )
             return i;
     }
 
diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
index ac34c69855..c7deaba109 100644
--- a/xen/arch/x86/include/asm/setup.h
+++ b/xen/arch/x86/include/asm/setup.h
@@ -36,11 +36,11 @@ extern struct boot_info xen_boot_info;
 unsigned long initial_images_nrpages(nodeid_t node);
 void free_boot_modules(void);
 
-struct boot_module;
-void *bootstrap_map_bm(const struct boot_module *bm);
+struct bootmodule;
+void *bootstrap_map_bm(const struct bootmodule *bm);
 void bootstrap_unmap(void);
 
-void release_boot_module(struct boot_module *bm);
+void release_boot_module(struct bootmodule *bm);
 
 struct rangeset;
 int remove_xen_ranges(struct rangeset *r);
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index e1b78d47c2..e6c77413f5 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -374,8 +374,8 @@ static int __init dom0_construct(const struct boot_domain *bd)
     struct domain *d = bd->d;
     struct vcpu *v = d->vcpu[0];
 
-    struct boot_module *image = bd->kernel;
-    struct boot_module *initrd = bd->module;
+    struct bootmodule *image = bd->kernel;
+    struct bootmodule *initrd = bd->module;
     void *image_base;
     unsigned long image_len;
     void *image_start;
@@ -422,7 +422,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
 
     image_base = bootstrap_map_bm(image);
     image_len = image->size;
-    image_start = image_base + image->headroom;
+    image_start = image_base + image->arch.headroom;
 
     d->max_pages = ~0U;
 
@@ -659,7 +659,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
              * pages. Tell the boot_module handling that we've freed it, so the
              * memory is left alone.
              */
-            initrd->released = true;
+            initrd->arch.released = true;
         }
 
         iommu_memory_setup(d, "initrd", mfn_to_page(_mfn(initrd_mfn)),
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 5da9df33c9..a6b3dbfc8c 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -298,7 +298,7 @@ struct boot_info __initdata xen_boot_info = {
     .loader = "unknown",
     .cmdline = "",
     .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } },
-    .mods = { [0 ... MAX_NR_BOOTMODS] = { .type = BOOTMOD_UNKNOWN } },
+    .mods = { [0 ... MAX_NR_BOOTMODS] = { .kind = BOOTMOD_UNKNOWN } },
 };
 
 static struct boot_info *__init multiboot_fill_boot_info(
@@ -333,7 +333,7 @@ static struct boot_info *__init multiboot_fill_boot_info(
      */
     for ( i = 0; i < MAX_NR_BOOTMODS && i < bi->nr_modules; i++ )
     {
-        bi->mods[i].cmdline_pa = mods[i].string;
+        bi->mods[i].arch.cmdline_pa = mods[i].string;
 
         if ( efi_enabled(EFI_LOADER) )
         {
@@ -356,7 +356,7 @@ static struct boot_info *__init multiboot_fill_boot_info(
     }
 
     /* Variable 'i' should be one entry past the last module. */
-    bi->mods[i].type = BOOTMOD_XEN;
+    bi->mods[i].kind = BOOTMOD_XEN;
 
     return bi;
 }
@@ -381,13 +381,13 @@ unsigned long __init initial_images_nrpages(nodeid_t node)
     return nr;
 }
 
-void __init release_boot_module(struct boot_module *bm)
+void __init release_boot_module(struct bootmodule *bm)
 {
-    ASSERT(!bm->released);
+    ASSERT(!bm->arch.released);
 
     init_domheap_pages(bm->start, bm->start + PAGE_ALIGN(bm->size));
 
-    bm->released = true;
+    bm->arch.released = true;
 }
 
 void __init free_boot_modules(void)
@@ -397,7 +397,7 @@ void __init free_boot_modules(void)
 
     for ( i = 0; i < bi->nr_modules; ++i )
     {
-        if ( bi->mods[i].released )
+        if ( bi->mods[i].arch.released )
             continue;
 
         release_boot_module(&bi->mods[i]);
@@ -519,7 +519,7 @@ static void *__init bootstrap_map_addr(paddr_t start, paddr_t end)
     return ret;
 }
 
-void *__init bootstrap_map_bm(const struct boot_module *bm)
+void *__init bootstrap_map_bm(const struct bootmodule *bm)
 {
     return bootstrap_map_addr(bm->start, bm->start + bm->size);
 }
@@ -689,7 +689,7 @@ static void __init noinline move_xen(void)
 #undef BOOTSTRAP_MAP_LIMIT
 
 static uint64_t __init consider_modules(
-    uint64_t s, uint64_t e, uint32_t size, const struct boot_module *mods,
+    uint64_t s, uint64_t e, uint32_t size, const struct bootmodule mods[],
     unsigned int nr_mods, unsigned int this_mod)
 {
     unsigned int i;
@@ -985,8 +985,9 @@ static size_t __init domain_cmdline_size(const struct boot_info *bi,
                                          const struct boot_domain *bd)
 {
     size_t s = bi->kextra ? strlen(bi->kextra) : 0;
+    const struct arch_bootmodule *abm = &bd->kernel->arch;
 
-    s += bd->kernel->cmdline_pa ? strlen(__va(bd->kernel->cmdline_pa)) : 0;
+    s += abm->cmdline_pa ? strlen(__va(abm->cmdline_pa)) : 0;
 
     if ( s == 0 )
         return s;
@@ -1050,9 +1051,10 @@ static struct domain *__init create_dom0(struct boot_info *bi)
         if ( !(cmdline = xzalloc_array(char, cmdline_size)) )
             panic("Error allocating cmdline buffer for %pd\n", d);
 
-        if ( bd->kernel->cmdline_pa )
+        if ( bd->kernel->arch.cmdline_pa )
             strlcpy(cmdline,
-                    cmdline_cook(__va(bd->kernel->cmdline_pa), bi->loader),
+                    cmdline_cook(__va(bd->kernel->arch.cmdline_pa),
+                                 bi->loader),
                     cmdline_size);
 
         if ( bi->kextra )
@@ -1074,7 +1076,7 @@ static struct domain *__init create_dom0(struct boot_info *bi)
             strlcat(cmdline, " acpi=", cmdline_size);
             strlcat(cmdline, acpi_param, cmdline_size);
         }
-        bd->kernel->cmdline_pa = 0;
+        bd->kernel->arch.cmdline_pa = 0;
         bd->cmdline = cmdline;
     }
 
@@ -1287,7 +1289,7 @@ void asmlinkage __init noreturn __start_xen(void)
     }
 
     /* Dom0 kernel is always first */
-    bi->mods[0].type = BOOTMOD_KERNEL;
+    bi->mods[0].kind = BOOTMOD_KERNEL;
     bi->domains[0].kernel = &bi->mods[0];
 
     if ( pvh_boot )
@@ -1458,7 +1460,7 @@ void asmlinkage __init noreturn __start_xen(void)
 
     if ( xen_phys_start )
     {
-        struct boot_module *xen = &bi->mods[bi->nr_modules];
+        struct bootmodule *xen = &bi->mods[bi->nr_modules];
 
         relocated = true;
 
@@ -1471,7 +1473,7 @@ void asmlinkage __init noreturn __start_xen(void)
         xen->size  = __2M_rwdata_end - _stext;
     }
 
-    bi->mods[0].headroom =
+    bi->mods[0].arch.headroom =
         bzimage_headroom(bootstrap_map_bm(&bi->mods[0]), bi->mods[0].size);
     bootstrap_unmap();
 
@@ -1552,10 +1554,10 @@ void asmlinkage __init noreturn __start_xen(void)
         /* Is the region suitable for relocating the multiboot modules? */
         for ( j = bi->nr_modules - 1; j >= 0; j-- )
         {
-            struct boot_module *bm = &bi->mods[j];
-            unsigned long size = PAGE_ALIGN(bm->headroom + bm->size);
+            struct bootmodule *bm = &bi->mods[j];
+            unsigned long size = PAGE_ALIGN(bm->arch.headroom + bm->size);
 
-            if ( bm->relocated )
+            if ( bm->arch.relocated )
                 continue;
 
             /* Don't overlap with other modules (or Xen itself). */
@@ -1565,12 +1567,12 @@ void asmlinkage __init noreturn __start_xen(void)
             if ( highmem_start && end > highmem_start )
                 continue;
 
-            if ( s < end && (bm->headroom || (end - size) > bm->start) )
+            if ( s < end && (bm->arch.headroom || (end - size) > bm->start) )
             {
-                move_memory(end - size + bm->headroom, bm->start, bm->size);
+                move_memory(end - size + bm->arch.headroom, bm->start, bm->size);
                 bm->start = (end - size);
-                bm->size += bm->headroom;
-                bm->relocated = true;
+                bm->size += bm->arch.headroom;
+                bm->arch.relocated = true;
             }
         }
 
@@ -1596,7 +1598,7 @@ void asmlinkage __init noreturn __start_xen(void)
 #endif
     }
 
-    if ( bi->mods[0].headroom && !bi->mods[0].relocated )
+    if ( bi->mods[0].arch.headroom && !bi->mods[0].arch.relocated )
         panic("Not enough memory to relocate the dom0 kernel image\n");
     for ( i = 0; i < bi->nr_modules; ++i )
     {
@@ -2154,7 +2156,7 @@ void asmlinkage __init noreturn __start_xen(void)
     initrdidx = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
     if ( initrdidx < MAX_NR_BOOTMODS )
     {
-        bi->mods[initrdidx].type = BOOTMOD_RAMDISK;
+        bi->mods[initrdidx].kind = BOOTMOD_RAMDISK;
         bi->domains[0].module = &bi->mods[initrdidx];
         if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
             printk(XENLOG_WARNING
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index d503d1bd4b..fa65e8fcf4 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -7,6 +7,10 @@
 #include <xen/macros.h>
 #include <xen/xmalloc.h>
 
+#if __has_include(<asm/bootfdt.h>)
+#include <asm/bootfdt.h>
+#endif
+
 #define MIN_FDT_ALIGN 8
 
 #define NR_MEM_BANKS 256
@@ -106,8 +110,13 @@ struct shared_meminfo {
 struct bootmodule {
     bootmodule_kind kind;
     bool domU;
+
     paddr_t start;
     paddr_t size;
+
+#if __has_include(<asm/bootfdt.h>)
+    struct arch_bootmodule arch;
+#endif
 };
 
 /* DT_MAX_NAME is the node name max length according the DT spec */
diff --git a/xen/xsm/xsm_policy.c b/xen/xsm/xsm_policy.c
index 7f70d860bd..0c2cdea8ed 100644
--- a/xen/xsm/xsm_policy.c
+++ b/xen/xsm/xsm_policy.c
@@ -40,7 +40,7 @@ int __init xsm_multiboot_policy_init(
 
     for_each_boot_module_by_type ( i, bi, BOOTMOD_UNKNOWN )
     {
-        struct boot_module *bm = &bi->mods[i];
+        struct bootmodule *bm = &bi->mods[i];
 
         _policy_start = bootstrap_map_bm(bm);
         _policy_len   = bm->size;
@@ -53,7 +53,7 @@ int __init xsm_multiboot_policy_init(
             printk("Policy len %#lx, start at %p.\n",
                    _policy_len,_policy_start);
 
-            bm->type = BOOTMOD_XSM_POLICY;
+            bm->kind = BOOTMOD_XSM;
             break;
 
         }
-- 
2.43.0

Re: [PATCH 10/19] x86: Replace boot_module with bootmodule

[Stefano Stabellini]

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> These types resemble each other very closely in layout and intent, and
> with "struct bootmodule" already in common code it makes perfect sense
> to merge them. In order to do so, add an arch-specific area for
> x86-specific tidbits.
> 
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
> ---
>  xen/arch/x86/cpu/microcode/core.c      |  9 ++--
>  xen/arch/x86/hvm/dom0_build.c          | 10 ++---
>  xen/arch/x86/include/asm/boot-domain.h |  4 +-
>  xen/arch/x86/include/asm/bootfdt.h     | 52 +++++++++++++++++++++++
>  xen/arch/x86/include/asm/bootinfo.h    | 58 +++-----------------------
>  xen/arch/x86/include/asm/setup.h       |  6 +--
>  xen/arch/x86/pv/dom0_build.c           |  8 ++--
>  xen/arch/x86/setup.c                   | 52 ++++++++++++-----------
>  xen/include/xen/bootfdt.h              |  9 ++++
>  xen/xsm/xsm_policy.c                   |  4 +-
>  10 files changed, 113 insertions(+), 99 deletions(-)
>  create mode 100644 xen/arch/x86/include/asm/bootfdt.h
> 
> diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c
> index 34a94cd25b..0111ef9156 100644
> --- a/xen/arch/x86/cpu/microcode/core.c
> +++ b/xen/arch/x86/cpu/microcode/core.c
> @@ -760,12 +760,11 @@ static int __init early_microcode_load(struct boot_info *bi)
>      {
>          for ( idx = 0; idx < bi->nr_modules; ++idx )
>          {
> -            const struct boot_module *bm = &bi->mods[idx];
> +            const struct bootmodule *bm = &bi->mods[idx];
>              struct cpio_data cd;
>  
>              /* Search anything unclaimed or likely to be a CPIO archive. */
> -            if ( bm->type != BOOTMOD_UNKNOWN &&
> -                 bm->type != BOOTMOD_RAMDISK )
> +            if ( bm->kind != BOOTMOD_UNKNOWN && bm->kind != BOOTMOD_RAMDISK )
>                  continue;
>  
>              size = bm->size;
> @@ -815,12 +814,12 @@ static int __init early_microcode_load(struct boot_info *bi)
>              return -ENODEV;
>          }
>  
> -        if ( bi->mods[idx].type != BOOTMOD_UNKNOWN )
> +        if ( bi->mods[idx].kind != BOOTMOD_UNKNOWN )
>          {
>              printk(XENLOG_WARNING "Microcode: Chosen module %d already used\n", idx);
>              return -ENODEV;
>          }
> -        bi->mods[idx].type = BOOTMOD_MICROCODE;
> +        bi->mods[idx].kind = BOOTMOD_MICROCODE;
>  
>          size = bi->mods[idx].size;
>          data = bootstrap_map_bm(&bi->mods[idx]);
> diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
> index a038e58c11..96410344a8 100644
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -647,10 +647,10 @@ static int __init pvh_load_kernel(
>      const struct boot_domain *bd, paddr_t *entry, paddr_t *start_info_addr)
>  {
>      struct domain *d = bd->d;
> -    struct boot_module *image = bd->kernel;
> -    struct boot_module *initrd = bd->module;
> +    struct bootmodule *image = bd->kernel;
> +    struct bootmodule *initrd = bd->module;
>      void *image_base = bootstrap_map_bm(image);
> -    void *image_start = image_base + image->headroom;
> +    void *image_start = image_base + image->arch.headroom;
>      unsigned long image_len = image->size;
>      unsigned long initrd_len = initrd ? initrd->size : 0;
>      size_t cmdline_len = bd->cmdline ? strlen(bd->cmdline) + 1 : 0;
> @@ -721,9 +721,9 @@ static int __init pvh_load_kernel(
>      {
>          size_t initrd_space = elf_round_up(&elf, initrd_len);
>  
> -        if ( initrd->cmdline_pa )
> +        if ( initrd->arch.cmdline_pa )
>          {
> -            initrd_cmdline = __va(initrd->cmdline_pa);
> +            initrd_cmdline = __va(initrd->arch.cmdline_pa);
>              if ( !*initrd_cmdline )
>                  initrd_cmdline = NULL;
>          }
> diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
> index d7c6042e25..242e9c9c2b 100644
> --- a/xen/arch/x86/include/asm/boot-domain.h
> +++ b/xen/arch/x86/include/asm/boot-domain.h
> @@ -13,8 +13,8 @@
>  struct boot_domain {
>      domid_t domid;
>  
> -    struct boot_module *kernel;
> -    struct boot_module *module;
> +    struct bootmodule *kernel;
> +    struct bootmodule *module;
>      const char *cmdline;
>  
>      struct domain *d;
> diff --git a/xen/arch/x86/include/asm/bootfdt.h b/xen/arch/x86/include/asm/bootfdt.h
> new file mode 100644
> index 0000000000..c00de8c09b
> --- /dev/null
> +++ b/xen/arch/x86/include/asm/bootfdt.h
> @@ -0,0 +1,52 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ARCH_X86_BOOTFDT_H__
> +#define __ARCH_X86_BOOTFDT_H__

With the new convention this is just X86_BOOTFDT_H


> +#include <xen/types.h>
> +
> +struct arch_bootmodule
> +{
> +    /*
> +     * Module State Flags:
> +     *   relocated:   indicates module has been relocated in memory.
> +     *   released:    indicates module's pages have been freed.
> +     *   fdt_cmdline: indicates module's cmdline is in the FDT.
> +     */
> +    bool relocated:1;
> +    bool released:1;
> +    bool fdt_cmdline:1;

This is not actually used or needed in this patch?


> +    /*
> +     * A boot module may need decompressing by Xen.  Headroom is an estimate of
> +     * the additional space required to decompress the module.
> +     *
> +     * Headroom is accounted for at the start of the module.  Decompressing is
> +     * done in-place with input=start, output=start-headroom, expecting the
> +     * pointers to become equal (give or take some rounding) when decompression
> +     * is complete.
> +     *
> +     * Memory layout at boot:
> +     *
> +     *               start ----+
> +     *                         v
> +     *   |<-----headroom------>|<------size------->|
> +     *                         +-------------------+
> +     *                         | Compressed Module |
> +     *   +---------------------+-------------------+
> +     *   |           Decompressed Module           |
> +     *   +-----------------------------------------+
> +     */
> +    unsigned long headroom;
> +    paddr_t cmdline_pa;
> +};
> +
> +#endif /* __ARCH_X86_BOOTFDT_H__ */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
> index 3afc214c17..f3210b7d6a 100644
> --- a/xen/arch/x86/include/asm/bootinfo.h
> +++ b/xen/arch/x86/include/asm/bootinfo.h
> @@ -8,6 +8,7 @@
>  #ifndef X86_BOOTINFO_H
>  #define X86_BOOTINFO_H
>  
> +#include <xen/bootfdt.h>
>  #include <xen/init.h>
>  #include <xen/multiboot.h>
>  #include <xen/types.h>
> @@ -19,55 +20,6 @@
>  /* Max number of boot domains that Xen can construct */
>  #define MAX_NR_BOOTDOMS 1
>  
> -/* Boot module binary type / purpose */
> -enum bootmod_type {
> -    BOOTMOD_UNKNOWN,
> -    BOOTMOD_XEN,
> -    BOOTMOD_KERNEL,
> -    BOOTMOD_RAMDISK,
> -    BOOTMOD_MICROCODE,
> -    BOOTMOD_XSM_POLICY,
> -};
> -
> -struct boot_module {
> -    enum bootmod_type type;
> -
> -    /*
> -     * Module State Flags:
> -     *   relocated: indicates module has been relocated in memory.
> -     *   released:  indicates module's pages have been freed.
> -     */
> -    bool relocated:1;
> -    bool released:1;
> -
> -    /*
> -     * A boot module may need decompressing by Xen.  Headroom is an estimate of
> -     * the additional space required to decompress the module.
> -     *
> -     * Headroom is accounted for at the start of the module.  Decompressing is
> -     * done in-place with input=start, output=start-headroom, expecting the
> -     * pointers to become equal (give or take some rounding) when decompression
> -     * is complete.
> -     *
> -     * Memory layout at boot:
> -     *
> -     *               start ----+
> -     *                         v
> -     *   |<-----headroom------>|<------size------->|
> -     *                         +-------------------+
> -     *                         | Compressed Module |
> -     *   +---------------------+-------------------+
> -     *   |           Decompressed Module           |
> -     *   +-----------------------------------------+
> -     */
> -    unsigned long headroom;
> -
> -    paddr_t cmdline_pa;
> -
> -    paddr_t start;
> -    size_t size;
> -};
> -
>  /*
>   * Xen internal representation of information provided by the
>   * bootloader/environment, or derived from the information.
> @@ -81,7 +33,7 @@ struct boot_info {
>      size_t memmap_length;
>  
>      unsigned int nr_modules;
> -    struct boot_module mods[MAX_NR_BOOTMODS + 1];
> +    struct bootmodule mods[MAX_NR_BOOTMODS + 1];
>      struct boot_domain domains[MAX_NR_BOOTDOMS];
>  };
>  
> @@ -94,16 +46,16 @@ struct boot_info {
>   *      Failure - a value greater than MAX_NR_BOOTMODS
>   */
>  static inline unsigned int __init next_boot_module_index(
> -    const struct boot_info *bi, enum bootmod_type t, unsigned int start)
> +    const struct boot_info *bi, bootmodule_kind k, unsigned int start)
>  {
>      unsigned int i;
>  
> -    if ( t == BOOTMOD_XEN )
> +    if ( k == BOOTMOD_XEN )
>          return bi->nr_modules;
>  
>      for ( i = start; i < bi->nr_modules; i++ )
>      {
> -        if ( bi->mods[i].type == t )
> +        if ( bi->mods[i].kind == k )
>              return i;
>      }
>  
> diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
> index ac34c69855..c7deaba109 100644
> --- a/xen/arch/x86/include/asm/setup.h
> +++ b/xen/arch/x86/include/asm/setup.h
> @@ -36,11 +36,11 @@ extern struct boot_info xen_boot_info;
>  unsigned long initial_images_nrpages(nodeid_t node);
>  void free_boot_modules(void);
>  
> -struct boot_module;
> -void *bootstrap_map_bm(const struct boot_module *bm);
> +struct bootmodule;
> +void *bootstrap_map_bm(const struct bootmodule *bm);
>  void bootstrap_unmap(void);
>  
> -void release_boot_module(struct boot_module *bm);
> +void release_boot_module(struct bootmodule *bm);
>  
>  struct rangeset;
>  int remove_xen_ranges(struct rangeset *r);
> diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
> index e1b78d47c2..e6c77413f5 100644
> --- a/xen/arch/x86/pv/dom0_build.c
> +++ b/xen/arch/x86/pv/dom0_build.c
> @@ -374,8 +374,8 @@ static int __init dom0_construct(const struct boot_domain *bd)
>      struct domain *d = bd->d;
>      struct vcpu *v = d->vcpu[0];
>  
> -    struct boot_module *image = bd->kernel;
> -    struct boot_module *initrd = bd->module;
> +    struct bootmodule *image = bd->kernel;
> +    struct bootmodule *initrd = bd->module;
>      void *image_base;
>      unsigned long image_len;
>      void *image_start;
> @@ -422,7 +422,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
>  
>      image_base = bootstrap_map_bm(image);
>      image_len = image->size;
> -    image_start = image_base + image->headroom;
> +    image_start = image_base + image->arch.headroom;
>  
>      d->max_pages = ~0U;
>  
> @@ -659,7 +659,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
>               * pages. Tell the boot_module handling that we've freed it, so the
>               * memory is left alone.
>               */
> -            initrd->released = true;
> +            initrd->arch.released = true;
>          }
>  
>          iommu_memory_setup(d, "initrd", mfn_to_page(_mfn(initrd_mfn)),
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 5da9df33c9..a6b3dbfc8c 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -298,7 +298,7 @@ struct boot_info __initdata xen_boot_info = {
>      .loader = "unknown",
>      .cmdline = "",
>      .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } },
> -    .mods = { [0 ... MAX_NR_BOOTMODS] = { .type = BOOTMOD_UNKNOWN } },
> +    .mods = { [0 ... MAX_NR_BOOTMODS] = { .kind = BOOTMOD_UNKNOWN } },
>  };
>  
>  static struct boot_info *__init multiboot_fill_boot_info(
> @@ -333,7 +333,7 @@ static struct boot_info *__init multiboot_fill_boot_info(
>       */
>      for ( i = 0; i < MAX_NR_BOOTMODS && i < bi->nr_modules; i++ )
>      {
> -        bi->mods[i].cmdline_pa = mods[i].string;
> +        bi->mods[i].arch.cmdline_pa = mods[i].string;
>  
>          if ( efi_enabled(EFI_LOADER) )
>          {
> @@ -356,7 +356,7 @@ static struct boot_info *__init multiboot_fill_boot_info(
>      }
>  
>      /* Variable 'i' should be one entry past the last module. */
> -    bi->mods[i].type = BOOTMOD_XEN;
> +    bi->mods[i].kind = BOOTMOD_XEN;
>  
>      return bi;
>  }
> @@ -381,13 +381,13 @@ unsigned long __init initial_images_nrpages(nodeid_t node)
>      return nr;
>  }
>  
> -void __init release_boot_module(struct boot_module *bm)
> +void __init release_boot_module(struct bootmodule *bm)
>  {
> -    ASSERT(!bm->released);
> +    ASSERT(!bm->arch.released);
>  
>      init_domheap_pages(bm->start, bm->start + PAGE_ALIGN(bm->size));
>  
> -    bm->released = true;
> +    bm->arch.released = true;
>  }
>  
>  void __init free_boot_modules(void)
> @@ -397,7 +397,7 @@ void __init free_boot_modules(void)
>  
>      for ( i = 0; i < bi->nr_modules; ++i )
>      {
> -        if ( bi->mods[i].released )
> +        if ( bi->mods[i].arch.released )
>              continue;
>  
>          release_boot_module(&bi->mods[i]);
> @@ -519,7 +519,7 @@ static void *__init bootstrap_map_addr(paddr_t start, paddr_t end)
>      return ret;
>  }
>  
> -void *__init bootstrap_map_bm(const struct boot_module *bm)
> +void *__init bootstrap_map_bm(const struct bootmodule *bm)
>  {
>      return bootstrap_map_addr(bm->start, bm->start + bm->size);
>  }
> @@ -689,7 +689,7 @@ static void __init noinline move_xen(void)
>  #undef BOOTSTRAP_MAP_LIMIT
>  
>  static uint64_t __init consider_modules(
> -    uint64_t s, uint64_t e, uint32_t size, const struct boot_module *mods,
> +    uint64_t s, uint64_t e, uint32_t size, const struct bootmodule mods[],
>      unsigned int nr_mods, unsigned int this_mod)
>  {
>      unsigned int i;
> @@ -985,8 +985,9 @@ static size_t __init domain_cmdline_size(const struct boot_info *bi,
>                                           const struct boot_domain *bd)
>  {
>      size_t s = bi->kextra ? strlen(bi->kextra) : 0;
> +    const struct arch_bootmodule *abm = &bd->kernel->arch;
>  
> -    s += bd->kernel->cmdline_pa ? strlen(__va(bd->kernel->cmdline_pa)) : 0;
> +    s += abm->cmdline_pa ? strlen(__va(abm->cmdline_pa)) : 0;
>  
>      if ( s == 0 )
>          return s;
> @@ -1050,9 +1051,10 @@ static struct domain *__init create_dom0(struct boot_info *bi)
>          if ( !(cmdline = xzalloc_array(char, cmdline_size)) )
>              panic("Error allocating cmdline buffer for %pd\n", d);
>  
> -        if ( bd->kernel->cmdline_pa )
> +        if ( bd->kernel->arch.cmdline_pa )
>              strlcpy(cmdline,
> -                    cmdline_cook(__va(bd->kernel->cmdline_pa), bi->loader),
> +                    cmdline_cook(__va(bd->kernel->arch.cmdline_pa),
> +                                 bi->loader),
>                      cmdline_size);
>  
>          if ( bi->kextra )
> @@ -1074,7 +1076,7 @@ static struct domain *__init create_dom0(struct boot_info *bi)
>              strlcat(cmdline, " acpi=", cmdline_size);
>              strlcat(cmdline, acpi_param, cmdline_size);
>          }
> -        bd->kernel->cmdline_pa = 0;
> +        bd->kernel->arch.cmdline_pa = 0;
>          bd->cmdline = cmdline;
>      }
>  
> @@ -1287,7 +1289,7 @@ void asmlinkage __init noreturn __start_xen(void)
>      }
>  
>      /* Dom0 kernel is always first */
> -    bi->mods[0].type = BOOTMOD_KERNEL;
> +    bi->mods[0].kind = BOOTMOD_KERNEL;
>      bi->domains[0].kernel = &bi->mods[0];
>  
>      if ( pvh_boot )
> @@ -1458,7 +1460,7 @@ void asmlinkage __init noreturn __start_xen(void)
>  
>      if ( xen_phys_start )
>      {
> -        struct boot_module *xen = &bi->mods[bi->nr_modules];
> +        struct bootmodule *xen = &bi->mods[bi->nr_modules];
>  
>          relocated = true;
>  
> @@ -1471,7 +1473,7 @@ void asmlinkage __init noreturn __start_xen(void)
>          xen->size  = __2M_rwdata_end - _stext;
>      }
>  
> -    bi->mods[0].headroom =
> +    bi->mods[0].arch.headroom =
>          bzimage_headroom(bootstrap_map_bm(&bi->mods[0]), bi->mods[0].size);
>      bootstrap_unmap();
>  
> @@ -1552,10 +1554,10 @@ void asmlinkage __init noreturn __start_xen(void)
>          /* Is the region suitable for relocating the multiboot modules? */
>          for ( j = bi->nr_modules - 1; j >= 0; j-- )
>          {
> -            struct boot_module *bm = &bi->mods[j];
> -            unsigned long size = PAGE_ALIGN(bm->headroom + bm->size);
> +            struct bootmodule *bm = &bi->mods[j];
> +            unsigned long size = PAGE_ALIGN(bm->arch.headroom + bm->size);
>  
> -            if ( bm->relocated )
> +            if ( bm->arch.relocated )
>                  continue;
>  
>              /* Don't overlap with other modules (or Xen itself). */
> @@ -1565,12 +1567,12 @@ void asmlinkage __init noreturn __start_xen(void)
>              if ( highmem_start && end > highmem_start )
>                  continue;
>  
> -            if ( s < end && (bm->headroom || (end - size) > bm->start) )
> +            if ( s < end && (bm->arch.headroom || (end - size) > bm->start) )
>              {
> -                move_memory(end - size + bm->headroom, bm->start, bm->size);
> +                move_memory(end - size + bm->arch.headroom, bm->start, bm->size);
>                  bm->start = (end - size);
> -                bm->size += bm->headroom;
> -                bm->relocated = true;
> +                bm->size += bm->arch.headroom;
> +                bm->arch.relocated = true;
>              }
>          }
>  
> @@ -1596,7 +1598,7 @@ void asmlinkage __init noreturn __start_xen(void)
>  #endif
>      }
>  
> -    if ( bi->mods[0].headroom && !bi->mods[0].relocated )
> +    if ( bi->mods[0].arch.headroom && !bi->mods[0].arch.relocated )
>          panic("Not enough memory to relocate the dom0 kernel image\n");
>      for ( i = 0; i < bi->nr_modules; ++i )
>      {
> @@ -2154,7 +2156,7 @@ void asmlinkage __init noreturn __start_xen(void)
>      initrdidx = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
>      if ( initrdidx < MAX_NR_BOOTMODS )
>      {
> -        bi->mods[initrdidx].type = BOOTMOD_RAMDISK;
> +        bi->mods[initrdidx].kind = BOOTMOD_RAMDISK;
>          bi->domains[0].module = &bi->mods[initrdidx];
>          if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
>              printk(XENLOG_WARNING
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index d503d1bd4b..fa65e8fcf4 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -7,6 +7,10 @@
>  #include <xen/macros.h>
>  #include <xen/xmalloc.h>
>  
> +#if __has_include(<asm/bootfdt.h>)
> +#include <asm/bootfdt.h>
> +#endif
> +
>  #define MIN_FDT_ALIGN 8
>  
>  #define NR_MEM_BANKS 256
> @@ -106,8 +110,13 @@ struct shared_meminfo {
>  struct bootmodule {
>      bootmodule_kind kind;
>      bool domU;
> +
>      paddr_t start;
>      paddr_t size;
> +
> +#if __has_include(<asm/bootfdt.h>)
> +    struct arch_bootmodule arch;
> +#endif
>  };
>  
>  /* DT_MAX_NAME is the node name max length according the DT spec */
> diff --git a/xen/xsm/xsm_policy.c b/xen/xsm/xsm_policy.c
> index 7f70d860bd..0c2cdea8ed 100644
> --- a/xen/xsm/xsm_policy.c
> +++ b/xen/xsm/xsm_policy.c
> @@ -40,7 +40,7 @@ int __init xsm_multiboot_policy_init(
>  
>      for_each_boot_module_by_type ( i, bi, BOOTMOD_UNKNOWN )
>      {
> -        struct boot_module *bm = &bi->mods[i];
> +        struct bootmodule *bm = &bi->mods[i];
>  
>          _policy_start = bootstrap_map_bm(bm);
>          _policy_len   = bm->size;
> @@ -53,7 +53,7 @@ int __init xsm_multiboot_policy_init(
>              printk("Policy len %#lx, start at %p.\n",
>                     _policy_len,_policy_start);
>  
> -            bm->type = BOOTMOD_XSM_POLICY;
> +            bm->kind = BOOTMOD_XSM;
>              break;
>  
>          }
> -- 
> 2.43.0
> 

Re: [PATCH 10/19] x86: Replace boot_module with bootmodule

[Alejandro Vallejo]

On Sat May 31, 2025 at 3:15 AM CEST, Stefano Stabellini wrote:
> On Fri, 30 May 2025, Alejandro Vallejo wrote:
>> These types resemble each other very closely in layout and intent, and
>> with "struct bootmodule" already in common code it makes perfect sense
>> to merge them. In order to do so, add an arch-specific area for
>> x86-specific tidbits.
>> 
>> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
>> ---
>>  xen/arch/x86/cpu/microcode/core.c      |  9 ++--
>>  xen/arch/x86/hvm/dom0_build.c          | 10 ++---
>>  xen/arch/x86/include/asm/boot-domain.h |  4 +-
>>  xen/arch/x86/include/asm/bootfdt.h     | 52 +++++++++++++++++++++++
>>  xen/arch/x86/include/asm/bootinfo.h    | 58 +++-----------------------
>>  xen/arch/x86/include/asm/setup.h       |  6 +--
>>  xen/arch/x86/pv/dom0_build.c           |  8 ++--
>>  xen/arch/x86/setup.c                   | 52 ++++++++++++-----------
>>  xen/include/xen/bootfdt.h              |  9 ++++
>>  xen/xsm/xsm_policy.c                   |  4 +-
>>  10 files changed, 113 insertions(+), 99 deletions(-)
>>  create mode 100644 xen/arch/x86/include/asm/bootfdt.h
>> 
>> diff --git a/xen/arch/x86/include/asm/bootfdt.h b/xen/arch/x86/include/asm/bootfdt.h
>> new file mode 100644
>> index 0000000000..c00de8c09b
>> --- /dev/null
>> +++ b/xen/arch/x86/include/asm/bootfdt.h
>> @@ -0,0 +1,52 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +#ifndef __ARCH_X86_BOOTFDT_H__
>> +#define __ARCH_X86_BOOTFDT_H__
>
> With the new convention this is just X86_BOOTFDT_H

Ah, right. I forgot about that. Sure.

>> +#include <xen/types.h>
>> +
>> +struct arch_bootmodule
>> +{
>> +    /*
>> +     * Module State Flags:
>> +     *   relocated:   indicates module has been relocated in memory.
>> +     *   released:    indicates module's pages have been freed.
>> +     *   fdt_cmdline: indicates module's cmdline is in the FDT.
>> +     */
>> +    bool relocated:1;
>> +    bool released:1;
>> +    bool fdt_cmdline:1;
>
> This is not actually used or needed in this patch?

Bah. This is a later addition in the dom0 DTB series. I pulled it
here too by mistake. Good catch.

Cheers,
Alejandro 

Re: [PATCH 10/19] x86: Replace boot_module with bootmodule

[Andrew Cooper]

On 30/05/2025 1:02 pm, Alejandro Vallejo wrote:
> These types resemble each other very closely in layout and intent, and
> with "struct bootmodule" already in common code it makes perfect sense
> to merge them. In order to do so, add an arch-specific area for
> x86-specific tidbits.
>
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>

Yet this is a distinct backwards step in terms of legibility.

How about modifying the common code to be more legible, rather than
regressing the x86 code.

~Andrew

Re: [PATCH 10/19] x86: Replace boot_module with bootmodule

[Alejandro Vallejo]

On Mon Jun 2, 2025 at 7:00 PM CEST, Andrew Cooper wrote:
> On 30/05/2025 1:02 pm, Alejandro Vallejo wrote:
>> These types resemble each other very closely in layout and intent, and
>> with "struct bootmodule" already in common code it makes perfect sense
>> to merge them. In order to do so, add an arch-specific area for
>> x86-specific tidbits.
>>
>> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
>
> Yet this is a distinct backwards step in terms of legibility.
>
> How about modifying the common code to be more legible, rather than
> regressing the x86 code.
>
> ~Andrew

I meant to ifdef out the fields unused on x86, but after some massaging I
think I got it lookin much nicer. It's essentially using the common parts of
kernel_info and boot_domain as a header to kernel_info.

That way, x86 keeps using a substantially smaller (yet common) data structure
while the rest of dom0less can keep using the original as-is.

Refactoring kernel_info to rationalise its contents is somewhere in my TODO
list, but I have much more urgent fish to fry first.

Cheers,
Alejandro

Re: [PATCH 10/19] x86: Replace boot_module with bootmodule

[Alejandro Vallejo]

On Thu Jun 5, 2025 at 7:28 PM CEST, Alejandro Vallejo wrote:
> On Mon Jun 2, 2025 at 7:00 PM CEST, Andrew Cooper wrote:
>> On 30/05/2025 1:02 pm, Alejandro Vallejo wrote:
>>> These types resemble each other very closely in layout and intent, and
>>> with "struct bootmodule" already in common code it makes perfect sense
>>> to merge them. In order to do so, add an arch-specific area for
>>> x86-specific tidbits.
>>>
>>> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
>>
>> Yet this is a distinct backwards step in terms of legibility.
>>
>> How about modifying the common code to be more legible, rather than
>> regressing the x86 code.
>>
>> ~Andrew
>
> I meant to ifdef out the fields unused on x86, but after some massaging I
> think I got it lookin much nicer. It's essentially using the common parts of
> kernel_info and boot_domain as a header to kernel_info.
>
> That way, x86 keeps using a substantially smaller (yet common) data structure
> while the rest of dom0less can keep using the original as-is.
>
> Refactoring kernel_info to rationalise its contents is somewhere in my TODO
> list, but I have much more urgent fish to fry first.
>
> Cheers,
> Alejandro

... I misread the comment and thought it was in the following patch rather than this one.

If it was indeed intended here, I'm at a loss as to what you'd rather do.
Common bindings need a common ground. This is such ground. The data structures
are virtually identical and used for identical purposes.

What's the legibility step you're talking about?

If not in this form, then in another, but I do need some data structure
understandable on every architecture for this very use or hooking dom0less
binding support from common in a non-hacky way becomes impossible.

Cheers,
Alejandro

Re: [PATCH 10/19] x86: Replace boot_module with bootmodule

[Jan Beulich]

On 05.06.2025 19:40, Alejandro Vallejo wrote:
> On Thu Jun 5, 2025 at 7:28 PM CEST, Alejandro Vallejo wrote:
>> On Mon Jun 2, 2025 at 7:00 PM CEST, Andrew Cooper wrote:
>>> On 30/05/2025 1:02 pm, Alejandro Vallejo wrote:
>>>> These types resemble each other very closely in layout and intent, and
>>>> with "struct bootmodule" already in common code it makes perfect sense
>>>> to merge them. In order to do so, add an arch-specific area for
>>>> x86-specific tidbits.
>>>>
>>>> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
>>>
>>> Yet this is a distinct backwards step in terms of legibility.
>>>
>>> How about modifying the common code to be more legible, rather than
>>> regressing the x86 code.
>>>
>>> ~Andrew
>>
>> I meant to ifdef out the fields unused on x86, but after some massaging I
>> think I got it lookin much nicer. It's essentially using the common parts of
>> kernel_info and boot_domain as a header to kernel_info.
>>
>> That way, x86 keeps using a substantially smaller (yet common) data structure
>> while the rest of dom0less can keep using the original as-is.
>>
>> Refactoring kernel_info to rationalise its contents is somewhere in my TODO
>> list, but I have much more urgent fish to fry first.
>>
>> Cheers,
>> Alejandro
> 
> ... I misread the comment and thought it was in the following patch rather than this one.
> 
> If it was indeed intended here, I'm at a loss as to what you'd rather do.
> Common bindings need a common ground. This is such ground. The data structures
> are virtually identical and used for identical purposes.
> 
> What's the legibility step you're talking about?

The loss of the underscore (separating the words) in the struct tag, aiui.

Jan

Re: [PATCH 10/19] x86: Replace boot_module with bootmodule

[Stefano Stabellini]

On Fri, 6 Jun 2025, Jan Beulich wrote:
> On 05.06.2025 19:40, Alejandro Vallejo wrote:
> > On Thu Jun 5, 2025 at 7:28 PM CEST, Alejandro Vallejo wrote:
> >> On Mon Jun 2, 2025 at 7:00 PM CEST, Andrew Cooper wrote:
> >>> On 30/05/2025 1:02 pm, Alejandro Vallejo wrote:
> >>>> These types resemble each other very closely in layout and intent, and
> >>>> with "struct bootmodule" already in common code it makes perfect sense
> >>>> to merge them. In order to do so, add an arch-specific area for
> >>>> x86-specific tidbits.
> >>>>
> >>>> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
> >>>
> >>> Yet this is a distinct backwards step in terms of legibility.
> >>>
> >>> How about modifying the common code to be more legible, rather than
> >>> regressing the x86 code.
> >>>
> >>> ~Andrew
> >>
> >> I meant to ifdef out the fields unused on x86, but after some massaging I
> >> think I got it lookin much nicer. It's essentially using the common parts of
> >> kernel_info and boot_domain as a header to kernel_info.
> >>
> >> That way, x86 keeps using a substantially smaller (yet common) data structure
> >> while the rest of dom0less can keep using the original as-is.
> >>
> >> Refactoring kernel_info to rationalise its contents is somewhere in my TODO
> >> list, but I have much more urgent fish to fry first.
> >>
> >> Cheers,
> >> Alejandro
> > 
> > ... I misread the comment and thought it was in the following patch rather than this one.
> > 
> > If it was indeed intended here, I'm at a loss as to what you'd rather do.
> > Common bindings need a common ground. This is such ground. The data structures
> > are virtually identical and used for identical purposes.
> > 
> > What's the legibility step you're talking about?
> 
> The loss of the underscore (separating the words) in the struct tag, aiui.

As I wrote in reply to the other patch, I would ask that we keep the
code movement and the renaming separate.

With that said, I don't mind a global s/bootmodule/boot_module/g across
the codebase, but please let's keep it as a separate patch to make it
easier to review.

However, we don't actually have a code style asking for _ in struct
tags. So while I don't mind the global s/bootmodule/boot_module/g, it
might be best we at least briefly discuss it as a group to make sure we
are all aligned.

[PATCH 11/19] x86: Replace boot_domain with kernel_info

[Alejandro Vallejo]

kernel_info and boot_domain serve basically the same role. Unify them so
they can be used in common code for domain building purposes across all
architectures.

kernel_info has a lot of fields x86 doesn't care about, but riscv and
arm do. Hence rather than moving them to the arch-specific files, x86
is ifdeffed out of those so arm and riscv can still keep sharing the
definitions.

Also, deconstify module pointers inside kernel_info, because x86 relies
on mutating through them.

Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
I'd be happier renaming struct kernel_info to struct bootdomain to clean
up the misnaming but I don't want to deal with the refactor in arm+riscv
right now. I've typedeffed it on x86 to bootdomain_t to reduce the diff
delta. (otherwise there's a lot of useless s/bd/ki/)

Some headers still use "struct kernel_info" in x86 to avoid extra includes.
Re-typedeffing only works from C11 onwards.

---
 xen/arch/x86/dom0_build.c              |  2 +-
 xen/arch/x86/hvm/dom0_build.c          | 10 ++++----
 xen/arch/x86/include/asm/boot-domain.h | 33 --------------------------
 xen/arch/x86/include/asm/bootinfo.h    |  7 ++++--
 xen/arch/x86/include/asm/dom0_build.h  |  6 ++---
 xen/arch/x86/include/asm/kernel.h      | 20 ++++++++++++++++
 xen/arch/x86/include/asm/setup.h       |  4 ++--
 xen/arch/x86/pv/dom0_build.c           |  8 +++----
 xen/arch/x86/setup.c                   | 26 ++++++++++----------
 xen/include/xen/fdt-kernel.h           |  2 +-
 10 files changed, 55 insertions(+), 63 deletions(-)
 delete mode 100644 xen/arch/x86/include/asm/boot-domain.h
 create mode 100644 xen/arch/x86/include/asm/kernel.h

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 0b467fd4a4..5bd4d39d10 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -615,7 +615,7 @@ int __init dom0_setup_permissions(struct domain *d)
     return rc;
 }
 
-int __init construct_dom0(const struct boot_domain *bd)
+int __init construct_dom0(const bootdomain_t *bd)
 {
     int rc;
     const struct domain *d = bd->d;
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 96410344a8..66d7046577 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -644,11 +644,11 @@ static bool __init check_and_adjust_load_address(
 }
 
 static int __init pvh_load_kernel(
-    const struct boot_domain *bd, paddr_t *entry, paddr_t *start_info_addr)
+    const bootdomain_t *bd, paddr_t *entry, paddr_t *start_info_addr)
 {
     struct domain *d = bd->d;
-    struct bootmodule *image = bd->kernel;
-    struct bootmodule *initrd = bd->module;
+    struct bootmodule *image = bd->kernel_bootmodule;
+    struct bootmodule *initrd = bd->initrd_bootmodule;
     void *image_base = bootstrap_map_bm(image);
     void *image_start = image_base + image->arch.headroom;
     unsigned long image_len = image->size;
@@ -1329,7 +1329,7 @@ static void __hwdom_init pvh_setup_mmcfg(struct domain *d)
     }
 }
 
-int __init dom0_construct_pvh(const struct boot_domain *bd)
+int __init dom0_construct_pvh(const bootdomain_t *bd)
 {
     paddr_t entry, start_info;
     struct domain *d = bd->d;
@@ -1337,7 +1337,7 @@ int __init dom0_construct_pvh(const struct boot_domain *bd)
 
     printk(XENLOG_INFO "*** Building a PVH Dom%d ***\n", d->domain_id);
 
-    if ( bd->kernel == NULL )
+    if ( bd->kernel_bootmodule == NULL )
         panic("Missing kernel boot module for %pd construction\n", d);
 
     if ( is_hardware_domain(d) )
diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
deleted file mode 100644
index 242e9c9c2b..0000000000
--- a/xen/arch/x86/include/asm/boot-domain.h
+++ /dev/null
@@ -1,33 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-or-later */
-/*
- * Copyright (c) 2024 Apertus Solutions, LLC
- * Author: Daniel P. Smith <dpsmith@apertussolutions.com>
- * Copyright (c) 2024 Christopher Clark <christopher.w.clark@gmail.com>
- */
-
-#ifndef __XEN_X86_BOOTDOMAIN_H__
-#define __XEN_X86_BOOTDOMAIN_H__
-
-#include <public/xen.h>
-
-struct boot_domain {
-    domid_t domid;
-
-    struct bootmodule *kernel;
-    struct bootmodule *module;
-    const char *cmdline;
-
-    struct domain *d;
-};
-
-#endif
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * tab-width: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
index f3210b7d6a..6b151c7759 100644
--- a/xen/arch/x86/include/asm/bootinfo.h
+++ b/xen/arch/x86/include/asm/bootinfo.h
@@ -9,10 +9,10 @@
 #define X86_BOOTINFO_H
 
 #include <xen/bootfdt.h>
+#include <xen/fdt-kernel.h>
 #include <xen/init.h>
 #include <xen/multiboot.h>
 #include <xen/types.h>
-#include <asm/boot-domain.h>
 
 /* Max number of boot modules a bootloader can provide in addition to Xen */
 #define MAX_NR_BOOTMODS 63
@@ -20,6 +20,9 @@
 /* Max number of boot domains that Xen can construct */
 #define MAX_NR_BOOTDOMS 1
 
+/* kernel_info is a misnomer. It holds information for a to-be domain. */
+typedef struct kernel_info bootdomain_t;
+
 /*
  * Xen internal representation of information provided by the
  * bootloader/environment, or derived from the information.
@@ -34,7 +37,7 @@ struct boot_info {
 
     unsigned int nr_modules;
     struct bootmodule mods[MAX_NR_BOOTMODS + 1];
-    struct boot_domain domains[MAX_NR_BOOTDOMS];
+    bootdomain_t domains[MAX_NR_BOOTDOMS];
 };
 
 /*
diff --git a/xen/arch/x86/include/asm/dom0_build.h b/xen/arch/x86/include/asm/dom0_build.h
index ff021c24af..68dc5e487c 100644
--- a/xen/arch/x86/include/asm/dom0_build.h
+++ b/xen/arch/x86/include/asm/dom0_build.h
@@ -13,9 +13,9 @@ unsigned long dom0_compute_nr_pages(struct domain *d,
                                     unsigned long initrd_len);
 int dom0_setup_permissions(struct domain *d);
 
-struct boot_domain;
-int dom0_construct_pv(const struct boot_domain *bd);
-int dom0_construct_pvh(const struct boot_domain *bd);
+struct kernel_info;
+int dom0_construct_pv(const struct kernel_info *bd);
+int dom0_construct_pvh(const struct kernel_info *bd);
 
 unsigned long dom0_paging_pages(const struct domain *d,
                                 unsigned long nr_pages);
diff --git a/xen/arch/x86/include/asm/kernel.h b/xen/arch/x86/include/asm/kernel.h
new file mode 100644
index 0000000000..f945f0957b
--- /dev/null
+++ b/xen/arch/x86/include/asm/kernel.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ARCH_X86_KERNEL_H__
+#define __ARCH_X86_KERNEL_H__
+
+#include <public/xen.h>
+
+typedef struct arch_kernel_info {
+    domid_t domid;
+} arch_bootdomain_t;
+
+#endif /* #__ARCH_X86_KERNEL_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
index c7deaba109..2183036da3 100644
--- a/xen/arch/x86/include/asm/setup.h
+++ b/xen/arch/x86/include/asm/setup.h
@@ -26,8 +26,8 @@ void subarch_init_memory(void);
 
 void init_IRQ(void);
 
-struct boot_domain;
-int construct_dom0(const struct boot_domain *bd);
+struct kernel_info; /* bootdomain_t */
+int construct_dom0(const struct kernel_info *bd);
 
 void setup_io_bitmap(struct domain *d);
 
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index e6c77413f5..2bb5d1bcdf 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -355,7 +355,7 @@ static struct page_info * __init alloc_chunk(struct domain *d,
     return page;
 }
 
-static int __init dom0_construct(const struct boot_domain *bd)
+static int __init dom0_construct(const bootdomain_t *bd)
 {
     unsigned int i;
     int rc, order, machine;
@@ -374,8 +374,8 @@ static int __init dom0_construct(const struct boot_domain *bd)
     struct domain *d = bd->d;
     struct vcpu *v = d->vcpu[0];
 
-    struct bootmodule *image = bd->kernel;
-    struct bootmodule *initrd = bd->module;
+    struct bootmodule *image = bd->kernel_bootmodule;
+    struct bootmodule *initrd = bd->initrd_bootmodule;
     void *image_base;
     unsigned long image_len;
     void *image_start;
@@ -1070,7 +1070,7 @@ out:
     return rc;
 }
 
-int __init dom0_construct_pv(const struct boot_domain *bd)
+int __init dom0_construct_pv(const bootdomain_t *bd)
 {
     unsigned long cr4 = read_cr4();
     int rc;
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index a6b3dbfc8c..aa3d913191 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -297,7 +297,9 @@ static const char *cmdline_cook(const char *p, const char *loader_name);
 struct boot_info __initdata xen_boot_info = {
     .loader = "unknown",
     .cmdline = "",
-    .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } },
+    .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = {
+        .arch = { .domid = DOMID_INVALID }
+    }},
     .mods = { [0 ... MAX_NR_BOOTMODS] = { .kind = BOOTMOD_UNKNOWN } },
 };
 
@@ -982,10 +984,10 @@ static unsigned int __init copy_bios_e820(struct e820entry *map, unsigned int li
 }
 
 static size_t __init domain_cmdline_size(const struct boot_info *bi,
-                                         const struct boot_domain *bd)
+                                         const bootdomain_t *bd)
 {
     size_t s = bi->kextra ? strlen(bi->kextra) : 0;
-    const struct arch_bootmodule *abm = &bd->kernel->arch;
+    const struct arch_bootmodule *abm = &bd->kernel_bootmodule->arch;
 
     s += abm->cmdline_pa ? strlen(__va(abm->cmdline_pa)) : 0;
 
@@ -1017,7 +1019,7 @@ static struct domain *__init create_dom0(struct boot_info *bi)
             .misc_flags = opt_dom0_msr_relaxed ? XEN_X86_MSR_RELAXED : 0,
         },
     };
-    struct boot_domain *bd = &bi->domains[0];
+    bootdomain_t *bd = &bi->domains[0];
     struct domain *d;
 
     if ( opt_dom0_pvh )
@@ -1034,11 +1036,11 @@ static struct domain *__init create_dom0(struct boot_info *bi)
         dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
 
     /* Create initial domain.  Not d0 for pvshim. */
-    bd->domid = get_initial_domain_id();
-    d = domain_create(bd->domid, &dom0_cfg,
+    bd->arch.domid = get_initial_domain_id();
+    d = domain_create(bd->arch.domid, &dom0_cfg,
                       pv_shim ? 0 : CDF_privileged | CDF_hardware);
     if ( IS_ERR(d) )
-        panic("Error creating d%u: %ld\n", bd->domid, PTR_ERR(d));
+        panic("Error creating d%u: %ld\n", bd->arch.domid, PTR_ERR(d));
 
     init_dom0_cpuid_policy(d);
 
@@ -1051,9 +1053,9 @@ static struct domain *__init create_dom0(struct boot_info *bi)
         if ( !(cmdline = xzalloc_array(char, cmdline_size)) )
             panic("Error allocating cmdline buffer for %pd\n", d);
 
-        if ( bd->kernel->arch.cmdline_pa )
+        if ( bd->kernel_bootmodule->arch.cmdline_pa )
             strlcpy(cmdline,
-                    cmdline_cook(__va(bd->kernel->arch.cmdline_pa),
+                    cmdline_cook(__va(bd->kernel_bootmodule->arch.cmdline_pa),
                                  bi->loader),
                     cmdline_size);
 
@@ -1076,7 +1078,7 @@ static struct domain *__init create_dom0(struct boot_info *bi)
             strlcat(cmdline, " acpi=", cmdline_size);
             strlcat(cmdline, acpi_param, cmdline_size);
         }
-        bd->kernel->arch.cmdline_pa = 0;
+        bd->kernel_bootmodule->arch.cmdline_pa = 0;
         bd->cmdline = cmdline;
     }
 
@@ -1290,7 +1292,7 @@ void asmlinkage __init noreturn __start_xen(void)
 
     /* Dom0 kernel is always first */
     bi->mods[0].kind = BOOTMOD_KERNEL;
-    bi->domains[0].kernel = &bi->mods[0];
+    bi->domains[0].kernel_bootmodule = &bi->mods[0];
 
     if ( pvh_boot )
     {
@@ -2157,7 +2159,7 @@ void asmlinkage __init noreturn __start_xen(void)
     if ( initrdidx < MAX_NR_BOOTMODS )
     {
         bi->mods[initrdidx].kind = BOOTMOD_RAMDISK;
-        bi->domains[0].module = &bi->mods[initrdidx];
+        bi->domains[0].initrd_bootmodule = &bi->mods[initrdidx];
         if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
             printk(XENLOG_WARNING
                    "Multiple initrd candidates, picking module #%u\n",
diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
index 1939c3ebf7..2f0ee42ebc 100644
--- a/xen/include/xen/fdt-kernel.h
+++ b/xen/include/xen/fdt-kernel.h
@@ -34,7 +34,7 @@ struct kernel_info {
     paddr_t gnttab_size;
 
     /* boot blob load addresses */
-    const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule;
+    struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule;
     const char* cmdline;
     paddr_t dtb_paddr;
     paddr_t initrd_paddr;
-- 
2.43.0

[PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h

[Alejandro Vallejo]

Part of an unpicking process to extract bootfdt contents independent of bootinfo
to a separate file for x86 to take.

Move functions required for early FDT parsing from device_tree.h and arm's
setup.h onto bootfdt.h

Declaration motion only. Not a functional change.

Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
 xen/arch/arm/include/asm/setup.h |  6 ----
 xen/include/xen/bootfdt.h        | 62 ++++++++++++++++++++++++++++++++
 xen/include/xen/device_tree.h    | 34 +-----------------
 3 files changed, 63 insertions(+), 39 deletions(-)

diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index 0f9e531a34..32308837a9 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -55,12 +55,6 @@ void setup_mm(void);
 extern uint32_t hyp_traps_vector[];
 void init_traps(void);
 
-void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
-                         uint32_t size_cells, paddr_t *start, paddr_t *size);
-
-u32 device_tree_get_u32(const void *fdt, int node,
-                        const char *prop_name, u32 dflt);
-
 int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt,
                   struct rangeset *iomem_ranges, struct rangeset *irq_ranges);
 
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index fa65e8fcf4..079259c719 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -2,6 +2,7 @@
 #ifndef XEN_BOOTFDT_H
 #define XEN_BOOTFDT_H
 
+#include <xen/byteorder.h>
 #include <xen/types.h>
 #include <xen/kernel.h>
 #include <xen/macros.h>
@@ -16,8 +17,53 @@
 #define NR_MEM_BANKS 256
 #define NR_SHMEM_BANKS 32
 
+/* Default #address and #size cells */
+#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
+#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
+
 #define MAX_MODULES 32 /* Current maximum useful modules */
 
+#define DEVICE_TREE_MAX_DEPTH 16
+
+/* Helper to read a big number; size is in cells (not bytes) */
+static inline u64 dt_read_number(const __be32 *cell, int size)
+{
+    u64 r = 0;
+
+    while ( size-- )
+        r = (r << 32) | be32_to_cpu(*(cell++));
+    return r;
+}
+
+static inline u64 dt_next_cell(int s, const __be32 **cellp)
+{
+    const __be32 *p = *cellp;
+
+    *cellp = p + s;
+    return dt_read_number(p, s);
+}
+
+typedef int (*device_tree_node_func)(const void *fdt,
+                                     int node, const char *name, int depth,
+                                     u32 address_cells, u32 size_cells,
+                                     void *data);
+
+/**
+ * device_tree_for_each_node - iterate over all device tree sub-nodes
+ * @fdt: flat device tree.
+ * @node: parent node to start the search from
+ * @func: function to call for each sub-node.
+ * @data: data to pass to @func.
+ *
+ * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
+ *
+ * Returns 0 if all nodes were iterated over successfully.  If @func
+ * returns a value different from 0, that value is returned immediately.
+ */
+int device_tree_for_each_node(const void *fdt, int node,
+                              device_tree_node_func func,
+                              void *data);
+
 typedef enum {
     BOOTMOD_XEN,
     BOOTMOD_FDT,
@@ -246,4 +292,20 @@ static inline struct membanks *membanks_xzalloc(unsigned int nr,
     return banks;
 }
 
+/*
+ * Interpret the property `prop_name` of `node` as a u32.
+ *
+ * Returns the property value on success; otherwise returns `dflt`.
+ */
+uint32_t device_tree_get_u32(const void *fdt, int node,
+                             const char *prop_name, uint32_t dflt);
+
+/*
+ * Interpret the property `prop_name` of `node` as a "reg".
+ *
+ * Returns outputs in `start` and `size`.
+ */
+void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
+                         uint32_t size_cells, paddr_t *start, paddr_t *size);
+
 #endif /* XEN_BOOTFDT_H */
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 6dc1fb5159..0a22b1ba1d 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -10,6 +10,7 @@
 #ifndef __XEN_DEVICE_TREE_H__
 #define __XEN_DEVICE_TREE_H__
 
+#include <xen/bootfdt.h>
 #include <xen/byteorder.h>
 
 #include <asm/device.h>
@@ -22,8 +23,6 @@
 #include <xen/list.h>
 #include <xen/rwlock.h>
 
-#define DEVICE_TREE_MAX_DEPTH 16
-
 /*
  * Struct used for matching a device
  */
@@ -164,17 +163,8 @@ struct dt_raw_irq {
     u32 specifier[DT_MAX_IRQ_SPEC];
 };
 
-typedef int (*device_tree_node_func)(const void *fdt,
-                                     int node, const char *name, int depth,
-                                     u32 address_cells, u32 size_cells,
-                                     void *data);
-
 extern const void *device_tree_flattened;
 
-int device_tree_for_each_node(const void *fdt, int node,
-                              device_tree_node_func func,
-                              void *data);
-
 /**
  * dt_unflatten_host_device_tree - Unflatten the host device tree
  *
@@ -245,10 +235,6 @@ void intc_dt_preinit(void);
 #define dt_node_cmp(s1, s2) strcasecmp((s1), (s2))
 #define dt_compat_cmp(s1, s2) strcasecmp((s1), (s2))
 
-/* Default #address and #size cells */
-#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
-#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
-
 #define dt_for_each_property_node(dn, pp)                   \
     for ( pp = (dn)->properties; (pp) != NULL; pp = (pp)->next )
 
@@ -258,16 +244,6 @@ void intc_dt_preinit(void);
 #define dt_for_each_child_node(dt, dn)                      \
     for ( dn = (dt)->child; (dn) != NULL; dn = (dn)->sibling )
 
-/* Helper to read a big number; size is in cells (not bytes) */
-static inline u64 dt_read_number(const __be32 *cell, int size)
-{
-    u64 r = 0;
-
-    while ( size-- )
-        r = (r << 32) | be32_to_cpu(*(cell++));
-    return r;
-}
-
 /* Wrapper for dt_read_number() to return paddr_t (instead of uint64_t) */
 static inline paddr_t dt_read_paddr(const __be32 *cell, int size)
 {
@@ -307,14 +283,6 @@ static inline int dt_size_to_cells(int bytes)
     return (bytes / sizeof(u32));
 }
 
-static inline u64 dt_next_cell(int s, const __be32 **cellp)
-{
-    const __be32 *p = *cellp;
-
-    *cellp = p + s;
-    return dt_read_number(p, s);
-}
-
 static inline const char *dt_node_full_name(const struct dt_device_node *np)
 {
     return (np && np->full_name) ? np->full_name : "<no-node>";
-- 
2.43.0

Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h

[dmkhn]

On Fri, May 30, 2025 at 02:02:20PM +0200, Alejandro Vallejo wrote:
> Part of an unpicking process to extract bootfdt contents independent of bootinfo
> to a separate file for x86 to take.
> 
> Move functions required for early FDT parsing from device_tree.h and arm's
> setup.h onto bootfdt.h
> 
> Declaration motion only. Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
> ---
>  xen/arch/arm/include/asm/setup.h |  6 ----
>  xen/include/xen/bootfdt.h        | 62 ++++++++++++++++++++++++++++++++
>  xen/include/xen/device_tree.h    | 34 +-----------------
>  3 files changed, 63 insertions(+), 39 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
> index 0f9e531a34..32308837a9 100644
> --- a/xen/arch/arm/include/asm/setup.h
> +++ b/xen/arch/arm/include/asm/setup.h
> @@ -55,12 +55,6 @@ void setup_mm(void);
>  extern uint32_t hyp_traps_vector[];
>  void init_traps(void);
> 
> -void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> -                         uint32_t size_cells, paddr_t *start, paddr_t *size);
> -
> -u32 device_tree_get_u32(const void *fdt, int node,
> -                        const char *prop_name, u32 dflt);
> -
>  int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt,
>                    struct rangeset *iomem_ranges, struct rangeset *irq_ranges);
> 
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index fa65e8fcf4..079259c719 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -2,6 +2,7 @@
>  #ifndef XEN_BOOTFDT_H
>  #define XEN_BOOTFDT_H
> 
> +#include <xen/byteorder.h>
>  #include <xen/types.h>
>  #include <xen/kernel.h>
>  #include <xen/macros.h>
> @@ -16,8 +17,53 @@
>  #define NR_MEM_BANKS 256
>  #define NR_SHMEM_BANKS 32
> 
> +/* Default #address and #size cells */
> +#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> +#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> +
>  #define MAX_MODULES 32 /* Current maximum useful modules */
> 
> +#define DEVICE_TREE_MAX_DEPTH 16
> +
> +/* Helper to read a big number; size is in cells (not bytes) */
> +static inline u64 dt_read_number(const __be32 *cell, int size)
> +{
> +    u64 r = 0;
> +
> +    while ( size-- )
> +        r = (r << 32) | be32_to_cpu(*(cell++));
> +    return r;
> +}
> +
> +static inline u64 dt_next_cell(int s, const __be32 **cellp)
> +{
> +    const __be32 *p = *cellp;
> +
> +    *cellp = p + s;
> +    return dt_read_number(p, s);
> +}
> +
> +typedef int (*device_tree_node_func)(const void *fdt,
> +                                     int node, const char *name, int depth,
> +                                     u32 address_cells, u32 size_cells,
> +                                     void *data);
> +
> +/**
> + * device_tree_for_each_node - iterate over all device tree sub-nodes
> + * @fdt: flat device tree.
> + * @node: parent node to start the search from
> + * @func: function to call for each sub-node.
> + * @data: data to pass to @func.
> + *
> + * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
> + *
> + * Returns 0 if all nodes were iterated over successfully.  If @func
> + * returns a value different from 0, that value is returned immediately.
> + */
> +int device_tree_for_each_node(const void *fdt, int node,
> +                              device_tree_node_func func,
> +                              void *data);
> +
>  typedef enum {
>      BOOTMOD_XEN,
>      BOOTMOD_FDT,
> @@ -246,4 +292,20 @@ static inline struct membanks *membanks_xzalloc(unsigned int nr,
>      return banks;
>  }
> 
> +/*
> + * Interpret the property `prop_name` of `node` as a u32.
> + *
> + * Returns the property value on success; otherwise returns `dflt`.
> + */
> +uint32_t device_tree_get_u32(const void *fdt, int node,
> +                             const char *prop_name, uint32_t dflt);

Suggest using `dt_` prefix (or any other good prefix) for all functions
in this header for consistency: e.g. there's dt_read_number() but also
device_tree_get_u32().

> +
> +/*
> + * Interpret the property `prop_name` of `node` as a "reg".
> + *
> + * Returns outputs in `start` and `size`.
> + */
> +void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> +                         uint32_t size_cells, paddr_t *start, paddr_t *size);
> +
>  #endif /* XEN_BOOTFDT_H */
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 6dc1fb5159..0a22b1ba1d 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -10,6 +10,7 @@
>  #ifndef __XEN_DEVICE_TREE_H__
>  #define __XEN_DEVICE_TREE_H__
> 
> +#include <xen/bootfdt.h>
>  #include <xen/byteorder.h>
> 
>  #include <asm/device.h>
> @@ -22,8 +23,6 @@
>  #include <xen/list.h>
>  #include <xen/rwlock.h>
> 
> -#define DEVICE_TREE_MAX_DEPTH 16
> -
>  /*
>   * Struct used for matching a device
>   */
> @@ -164,17 +163,8 @@ struct dt_raw_irq {
>      u32 specifier[DT_MAX_IRQ_SPEC];
>  };
> 
> -typedef int (*device_tree_node_func)(const void *fdt,
> -                                     int node, const char *name, int depth,
> -                                     u32 address_cells, u32 size_cells,
> -                                     void *data);
> -
>  extern const void *device_tree_flattened;
> 
> -int device_tree_for_each_node(const void *fdt, int node,
> -                              device_tree_node_func func,
> -                              void *data);
> -
>  /**
>   * dt_unflatten_host_device_tree - Unflatten the host device tree
>   *
> @@ -245,10 +235,6 @@ void intc_dt_preinit(void);
>  #define dt_node_cmp(s1, s2) strcasecmp((s1), (s2))
>  #define dt_compat_cmp(s1, s2) strcasecmp((s1), (s2))
> 
> -/* Default #address and #size cells */
> -#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> -#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> -
>  #define dt_for_each_property_node(dn, pp)                   \
>      for ( pp = (dn)->properties; (pp) != NULL; pp = (pp)->next )
> 
> @@ -258,16 +244,6 @@ void intc_dt_preinit(void);
>  #define dt_for_each_child_node(dt, dn)                      \
>      for ( dn = (dt)->child; (dn) != NULL; dn = (dn)->sibling )
> 
> -/* Helper to read a big number; size is in cells (not bytes) */
> -static inline u64 dt_read_number(const __be32 *cell, int size)
> -{
> -    u64 r = 0;
> -
> -    while ( size-- )
> -        r = (r << 32) | be32_to_cpu(*(cell++));
> -    return r;
> -}
> -
>  /* Wrapper for dt_read_number() to return paddr_t (instead of uint64_t) */
>  static inline paddr_t dt_read_paddr(const __be32 *cell, int size)
>  {
> @@ -307,14 +283,6 @@ static inline int dt_size_to_cells(int bytes)
>      return (bytes / sizeof(u32));
>  }
> 
> -static inline u64 dt_next_cell(int s, const __be32 **cellp)
> -{
> -    const __be32 *p = *cellp;
> -
> -    *cellp = p + s;
> -    return dt_read_number(p, s);
> -}
> -
>  static inline const char *dt_node_full_name(const struct dt_device_node *np)
>  {
>      return (np && np->full_name) ? np->full_name : "<no-node>";
> --
> 2.43.0
> 
> 

Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h

[Orzel, Michal]

On 31/05/2025 02:35, dmkhn@proton.me wrote:
> On Fri, May 30, 2025 at 02:02:20PM +0200, Alejandro Vallejo wrote:
>> Part of an unpicking process to extract bootfdt contents independent of bootinfo
>> to a separate file for x86 to take.
>>
>> Move functions required for early FDT parsing from device_tree.h and arm's
>> setup.h onto bootfdt.h
>>
>> Declaration motion only. Not a functional change.
>>
>> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
>> ---
>>  xen/arch/arm/include/asm/setup.h |  6 ----
>>  xen/include/xen/bootfdt.h        | 62 ++++++++++++++++++++++++++++++++
>>  xen/include/xen/device_tree.h    | 34 +-----------------
>>  3 files changed, 63 insertions(+), 39 deletions(-)
>>
>> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
>> index 0f9e531a34..32308837a9 100644
>> --- a/xen/arch/arm/include/asm/setup.h
>> +++ b/xen/arch/arm/include/asm/setup.h
>> @@ -55,12 +55,6 @@ void setup_mm(void);
>>  extern uint32_t hyp_traps_vector[];
>>  void init_traps(void);
>>
>> -void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
>> -                         uint32_t size_cells, paddr_t *start, paddr_t *size);
>> -
>> -u32 device_tree_get_u32(const void *fdt, int node,
>> -                        const char *prop_name, u32 dflt);
>> -
>>  int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt,
>>                    struct rangeset *iomem_ranges, struct rangeset *irq_ranges);
>>
>> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
>> index fa65e8fcf4..079259c719 100644
>> --- a/xen/include/xen/bootfdt.h
>> +++ b/xen/include/xen/bootfdt.h
>> @@ -2,6 +2,7 @@
>>  #ifndef XEN_BOOTFDT_H
>>  #define XEN_BOOTFDT_H
>>
>> +#include <xen/byteorder.h>
>>  #include <xen/types.h>
>>  #include <xen/kernel.h>
>>  #include <xen/macros.h>
>> @@ -16,8 +17,53 @@
>>  #define NR_MEM_BANKS 256
>>  #define NR_SHMEM_BANKS 32
>>
>> +/* Default #address and #size cells */
>> +#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
>> +#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
>> +
>>  #define MAX_MODULES 32 /* Current maximum useful modules */
>>
>> +#define DEVICE_TREE_MAX_DEPTH 16
>> +
>> +/* Helper to read a big number; size is in cells (not bytes) */
>> +static inline u64 dt_read_number(const __be32 *cell, int size)
>> +{
>> +    u64 r = 0;
>> +
>> +    while ( size-- )
>> +        r = (r << 32) | be32_to_cpu(*(cell++));
>> +    return r;
>> +}
>> +
>> +static inline u64 dt_next_cell(int s, const __be32 **cellp)
>> +{
>> +    const __be32 *p = *cellp;
>> +
>> +    *cellp = p + s;
>> +    return dt_read_number(p, s);
>> +}
>> +
>> +typedef int (*device_tree_node_func)(const void *fdt,
>> +                                     int node, const char *name, int depth,
>> +                                     u32 address_cells, u32 size_cells,
>> +                                     void *data);
>> +
>> +/**
>> + * device_tree_for_each_node - iterate over all device tree sub-nodes
>> + * @fdt: flat device tree.
>> + * @node: parent node to start the search from
>> + * @func: function to call for each sub-node.
>> + * @data: data to pass to @func.
>> + *
>> + * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
>> + *
>> + * Returns 0 if all nodes were iterated over successfully.  If @func
>> + * returns a value different from 0, that value is returned immediately.
>> + */
>> +int device_tree_for_each_node(const void *fdt, int node,
>> +                              device_tree_node_func func,
>> +                              void *data);
>> +
>>  typedef enum {
>>      BOOTMOD_XEN,
>>      BOOTMOD_FDT,
>> @@ -246,4 +292,20 @@ static inline struct membanks *membanks_xzalloc(unsigned int nr,
>>      return banks;
>>  }
>>
>> +/*
>> + * Interpret the property `prop_name` of `node` as a u32.
>> + *
>> + * Returns the property value on success; otherwise returns `dflt`.
>> + */
>> +uint32_t device_tree_get_u32(const void *fdt, int node,
>> +                             const char *prop_name, uint32_t dflt);
> 
> Suggest using `dt_` prefix (or any other good prefix) for all functions
> in this header for consistency: e.g. there's dt_read_number() but also
> device_tree_get_u32().
Not really. AFAIR device_tree_ prefix is for functions operating on flattened DT
(usually calling libfdt functions inside) and dt_ otherwise. Let's not mix them.

~Michal

Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h

[dmkhn]

On Mon, Jun 02, 2025 at 09:29:16AM +0200, Orzel, Michal wrote:
> 
> 
> On 31/05/2025 02:35, dmkhn@proton.me wrote:
> > On Fri, May 30, 2025 at 02:02:20PM +0200, Alejandro Vallejo wrote:
> >> Part of an unpicking process to extract bootfdt contents independent of bootinfo
> >> to a separate file for x86 to take.
> >>
> >> Move functions required for early FDT parsing from device_tree.h and arm's
> >> setup.h onto bootfdt.h
> >>
> >> Declaration motion only. Not a functional change.
> >>
> >> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
> >> ---
> >>  xen/arch/arm/include/asm/setup.h |  6 ----
> >>  xen/include/xen/bootfdt.h        | 62 ++++++++++++++++++++++++++++++++
> >>  xen/include/xen/device_tree.h    | 34 +-----------------
> >>  3 files changed, 63 insertions(+), 39 deletions(-)
> >>
> >> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
> >> index 0f9e531a34..32308837a9 100644
> >> --- a/xen/arch/arm/include/asm/setup.h
> >> +++ b/xen/arch/arm/include/asm/setup.h
> >> @@ -55,12 +55,6 @@ void setup_mm(void);
> >>  extern uint32_t hyp_traps_vector[];
> >>  void init_traps(void);
> >>
> >> -void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> >> -                         uint32_t size_cells, paddr_t *start, paddr_t *size);
> >> -
> >> -u32 device_tree_get_u32(const void *fdt, int node,
> >> -                        const char *prop_name, u32 dflt);
> >> -
> >>  int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt,
> >>                    struct rangeset *iomem_ranges, struct rangeset *irq_ranges);
> >>
> >> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> >> index fa65e8fcf4..079259c719 100644
> >> --- a/xen/include/xen/bootfdt.h
> >> +++ b/xen/include/xen/bootfdt.h
> >> @@ -2,6 +2,7 @@
> >>  #ifndef XEN_BOOTFDT_H
> >>  #define XEN_BOOTFDT_H
> >>
> >> +#include <xen/byteorder.h>
> >>  #include <xen/types.h>
> >>  #include <xen/kernel.h>
> >>  #include <xen/macros.h>
> >> @@ -16,8 +17,53 @@
> >>  #define NR_MEM_BANKS 256
> >>  #define NR_SHMEM_BANKS 32
> >>
> >> +/* Default #address and #size cells */
> >> +#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> >> +#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> >> +
> >>  #define MAX_MODULES 32 /* Current maximum useful modules */
> >>
> >> +#define DEVICE_TREE_MAX_DEPTH 16
> >> +
> >> +/* Helper to read a big number; size is in cells (not bytes) */
> >> +static inline u64 dt_read_number(const __be32 *cell, int size)
> >> +{
> >> +    u64 r = 0;
> >> +
> >> +    while ( size-- )
> >> +        r = (r << 32) | be32_to_cpu(*(cell++));
> >> +    return r;
> >> +}
> >> +
> >> +static inline u64 dt_next_cell(int s, const __be32 **cellp)
> >> +{
> >> +    const __be32 *p = *cellp;
> >> +
> >> +    *cellp = p + s;
> >> +    return dt_read_number(p, s);
> >> +}
> >> +
> >> +typedef int (*device_tree_node_func)(const void *fdt,
> >> +                                     int node, const char *name, int depth,
> >> +                                     u32 address_cells, u32 size_cells,
> >> +                                     void *data);
> >> +
> >> +/**
> >> + * device_tree_for_each_node - iterate over all device tree sub-nodes
> >> + * @fdt: flat device tree.
> >> + * @node: parent node to start the search from
> >> + * @func: function to call for each sub-node.
> >> + * @data: data to pass to @func.
> >> + *
> >> + * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
> >> + *
> >> + * Returns 0 if all nodes were iterated over successfully.  If @func
> >> + * returns a value different from 0, that value is returned immediately.
> >> + */
> >> +int device_tree_for_each_node(const void *fdt, int node,
> >> +                              device_tree_node_func func,
> >> +                              void *data);
> >> +
> >>  typedef enum {
> >>      BOOTMOD_XEN,
> >>      BOOTMOD_FDT,
> >> @@ -246,4 +292,20 @@ static inline struct membanks *membanks_xzalloc(unsigned int nr,
> >>      return banks;
> >>  }
> >>
> >> +/*
> >> + * Interpret the property `prop_name` of `node` as a u32.
> >> + *
> >> + * Returns the property value on success; otherwise returns `dflt`.
> >> + */
> >> +uint32_t device_tree_get_u32(const void *fdt, int node,
> >> +                             const char *prop_name, uint32_t dflt);
> >
> > Suggest using `dt_` prefix (or any other good prefix) for all functions
> > in this header for consistency: e.g. there's dt_read_number() but also
> > device_tree_get_u32().
> Not really. AFAIR device_tree_ prefix is for functions operating on flattened DT
> (usually calling libfdt functions inside) and dt_ otherwise. Let's not mix them.

I see, thanks for explanation.
I would add a brief comment in this header to distinguish such difference then.

> 
> ~Michal
> 

Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h

[Alejandro Vallejo]

On Sat May 31, 2025 at 2:35 AM CEST, dmkhn wrote:
> On Fri, May 30, 2025 at 02:02:20PM +0200, Alejandro Vallejo wrote:
>> Part of an unpicking process to extract bootfdt contents independent of bootinfo
>> to a separate file for x86 to take.
>> 
>> Move functions required for early FDT parsing from device_tree.h and arm's
>> setup.h onto bootfdt.h
>> 
>> Declaration motion only. Not a functional change.
>> 
>> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
>> ---
>>  xen/arch/arm/include/asm/setup.h |  6 ----
>>  xen/include/xen/bootfdt.h        | 62 ++++++++++++++++++++++++++++++++
>>  xen/include/xen/device_tree.h    | 34 +-----------------
>>  3 files changed, 63 insertions(+), 39 deletions(-)
>> 
>> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
>> index 0f9e531a34..32308837a9 100644
>> --- a/xen/arch/arm/include/asm/setup.h
>> +++ b/xen/arch/arm/include/asm/setup.h
>> @@ -55,12 +55,6 @@ void setup_mm(void);
>>  extern uint32_t hyp_traps_vector[];
>>  void init_traps(void);
>> 
>> -void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
>> -                         uint32_t size_cells, paddr_t *start, paddr_t *size);
>> -
>> -u32 device_tree_get_u32(const void *fdt, int node,
>> -                        const char *prop_name, u32 dflt);
>> -
>>  int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt,
>>                    struct rangeset *iomem_ranges, struct rangeset *irq_ranges);
>> 
>> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
>> index fa65e8fcf4..079259c719 100644
>> --- a/xen/include/xen/bootfdt.h
>> +++ b/xen/include/xen/bootfdt.h
>> @@ -2,6 +2,7 @@
>>  #ifndef XEN_BOOTFDT_H
>>  #define XEN_BOOTFDT_H
>> 
>> +#include <xen/byteorder.h>
>>  #include <xen/types.h>
>>  #include <xen/kernel.h>
>>  #include <xen/macros.h>
>> @@ -16,8 +17,53 @@
>>  #define NR_MEM_BANKS 256
>>  #define NR_SHMEM_BANKS 32
>> 
>> +/* Default #address and #size cells */
>> +#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
>> +#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
>> +
>>  #define MAX_MODULES 32 /* Current maximum useful modules */
>> 
>> +#define DEVICE_TREE_MAX_DEPTH 16
>> +
>> +/* Helper to read a big number; size is in cells (not bytes) */
>> +static inline u64 dt_read_number(const __be32 *cell, int size)
>> +{
>> +    u64 r = 0;
>> +
>> +    while ( size-- )
>> +        r = (r << 32) | be32_to_cpu(*(cell++));
>> +    return r;
>> +}
>> +
>> +static inline u64 dt_next_cell(int s, const __be32 **cellp)
>> +{
>> +    const __be32 *p = *cellp;
>> +
>> +    *cellp = p + s;
>> +    return dt_read_number(p, s);
>> +}
>> +
>> +typedef int (*device_tree_node_func)(const void *fdt,
>> +                                     int node, const char *name, int depth,
>> +                                     u32 address_cells, u32 size_cells,
>> +                                     void *data);
>> +
>> +/**
>> + * device_tree_for_each_node - iterate over all device tree sub-nodes
>> + * @fdt: flat device tree.
>> + * @node: parent node to start the search from
>> + * @func: function to call for each sub-node.
>> + * @data: data to pass to @func.
>> + *
>> + * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
>> + *
>> + * Returns 0 if all nodes were iterated over successfully.  If @func
>> + * returns a value different from 0, that value is returned immediately.
>> + */
>> +int device_tree_for_each_node(const void *fdt, int node,
>> +                              device_tree_node_func func,
>> +                              void *data);
>> +
>>  typedef enum {
>>      BOOTMOD_XEN,
>>      BOOTMOD_FDT,
>> @@ -246,4 +292,20 @@ static inline struct membanks *membanks_xzalloc(unsigned int nr,
>>      return banks;
>>  }
>> 
>> +/*
>> + * Interpret the property `prop_name` of `node` as a u32.
>> + *
>> + * Returns the property value on success; otherwise returns `dflt`.
>> + */
>> +uint32_t device_tree_get_u32(const void *fdt, int node,
>> +                             const char *prop_name, uint32_t dflt);
>
> Suggest using `dt_` prefix (or any other good prefix) for all functions
> in this header for consistency: e.g. there's dt_read_number() but also
> device_tree_get_u32().

I'd be quite happy with an fdt_ prefix, to clearly show they relate to FDTs.

But I didn't want to do that right away because it would obscure the strict code
motion that's going on.

>
>> +
>> +/*
>> + * Interpret the property `prop_name` of `node` as a "reg".
>> + *
>> + * Returns outputs in `start` and `size`.
>> + */
>> +void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
>> +                         uint32_t size_cells, paddr_t *start, paddr_t *size);
>> +
>>  #endif /* XEN_BOOTFDT_H */
>> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
>> index 6dc1fb5159..0a22b1ba1d 100644
>> --- a/xen/include/xen/device_tree.h
>> +++ b/xen/include/xen/device_tree.h
>> @@ -10,6 +10,7 @@
>>  #ifndef __XEN_DEVICE_TREE_H__
>>  #define __XEN_DEVICE_TREE_H__
>> 
>> +#include <xen/bootfdt.h>
>>  #include <xen/byteorder.h>
>> 
>>  #include <asm/device.h>
>> @@ -22,8 +23,6 @@
>>  #include <xen/list.h>
>>  #include <xen/rwlock.h>
>> 
>> -#define DEVICE_TREE_MAX_DEPTH 16
>> -
>>  /*
>>   * Struct used for matching a device
>>   */
>> @@ -164,17 +163,8 @@ struct dt_raw_irq {
>>      u32 specifier[DT_MAX_IRQ_SPEC];
>>  };
>> 
>> -typedef int (*device_tree_node_func)(const void *fdt,
>> -                                     int node, const char *name, int depth,
>> -                                     u32 address_cells, u32 size_cells,
>> -                                     void *data);
>> -
>>  extern const void *device_tree_flattened;
>> 
>> -int device_tree_for_each_node(const void *fdt, int node,
>> -                              device_tree_node_func func,
>> -                              void *data);
>> -
>>  /**
>>   * dt_unflatten_host_device_tree - Unflatten the host device tree
>>   *
>> @@ -245,10 +235,6 @@ void intc_dt_preinit(void);
>>  #define dt_node_cmp(s1, s2) strcasecmp((s1), (s2))
>>  #define dt_compat_cmp(s1, s2) strcasecmp((s1), (s2))
>> 
>> -/* Default #address and #size cells */
>> -#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
>> -#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
>> -
>>  #define dt_for_each_property_node(dn, pp)                   \
>>      for ( pp = (dn)->properties; (pp) != NULL; pp = (pp)->next )
>> 
>> @@ -258,16 +244,6 @@ void intc_dt_preinit(void);
>>  #define dt_for_each_child_node(dt, dn)                      \
>>      for ( dn = (dt)->child; (dn) != NULL; dn = (dn)->sibling )
>> 
>> -/* Helper to read a big number; size is in cells (not bytes) */
>> -static inline u64 dt_read_number(const __be32 *cell, int size)
>> -{
>> -    u64 r = 0;
>> -
>> -    while ( size-- )
>> -        r = (r << 32) | be32_to_cpu(*(cell++));
>> -    return r;
>> -}
>> -
>>  /* Wrapper for dt_read_number() to return paddr_t (instead of uint64_t) */
>>  static inline paddr_t dt_read_paddr(const __be32 *cell, int size)
>>  {
>> @@ -307,14 +283,6 @@ static inline int dt_size_to_cells(int bytes)
>>      return (bytes / sizeof(u32));
>>  }
>> 
>> -static inline u64 dt_next_cell(int s, const __be32 **cellp)
>> -{
>> -    const __be32 *p = *cellp;
>> -
>> -    *cellp = p + s;
>> -    return dt_read_number(p, s);
>> -}
>> -
>>  static inline const char *dt_node_full_name(const struct dt_device_node *np)
>>  {
>>      return (np && np->full_name) ? np->full_name : "<no-node>";
>> --
>> 2.43.0
>> 
>> 

Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h

[dmkhn]

On Mon, Jun 02, 2025 at 06:41:32PM +0200, Alejandro Vallejo wrote:
> On Sat May 31, 2025 at 2:35 AM CEST, dmkhn wrote:
> > On Fri, May 30, 2025 at 02:02:20PM +0200, Alejandro Vallejo wrote:
> >> Part of an unpicking process to extract bootfdt contents independent of bootinfo
> >> to a separate file for x86 to take.
> >>
> >> Move functions required for early FDT parsing from device_tree.h and arm's
> >> setup.h onto bootfdt.h
> >>
> >> Declaration motion only. Not a functional change.
> >>
> >> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
> >> ---
> >>  xen/arch/arm/include/asm/setup.h |  6 ----
> >>  xen/include/xen/bootfdt.h        | 62 ++++++++++++++++++++++++++++++++
> >>  xen/include/xen/device_tree.h    | 34 +-----------------
> >>  3 files changed, 63 insertions(+), 39 deletions(-)
> >>
> >> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
> >> index 0f9e531a34..32308837a9 100644
> >> --- a/xen/arch/arm/include/asm/setup.h
> >> +++ b/xen/arch/arm/include/asm/setup.h
> >> @@ -55,12 +55,6 @@ void setup_mm(void);
> >>  extern uint32_t hyp_traps_vector[];
> >>  void init_traps(void);
> >>
> >> -void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> >> -                         uint32_t size_cells, paddr_t *start, paddr_t *size);
> >> -
> >> -u32 device_tree_get_u32(const void *fdt, int node,
> >> -                        const char *prop_name, u32 dflt);
> >> -
> >>  int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt,
> >>                    struct rangeset *iomem_ranges, struct rangeset *irq_ranges);
> >>
> >> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> >> index fa65e8fcf4..079259c719 100644
> >> --- a/xen/include/xen/bootfdt.h
> >> +++ b/xen/include/xen/bootfdt.h
> >> @@ -2,6 +2,7 @@
> >>  #ifndef XEN_BOOTFDT_H
> >>  #define XEN_BOOTFDT_H
> >>
> >> +#include <xen/byteorder.h>
> >>  #include <xen/types.h>
> >>  #include <xen/kernel.h>
> >>  #include <xen/macros.h>
> >> @@ -16,8 +17,53 @@
> >>  #define NR_MEM_BANKS 256
> >>  #define NR_SHMEM_BANKS 32
> >>
> >> +/* Default #address and #size cells */
> >> +#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> >> +#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> >> +
> >>  #define MAX_MODULES 32 /* Current maximum useful modules */
> >>
> >> +#define DEVICE_TREE_MAX_DEPTH 16
> >> +
> >> +/* Helper to read a big number; size is in cells (not bytes) */
> >> +static inline u64 dt_read_number(const __be32 *cell, int size)
> >> +{
> >> +    u64 r = 0;
> >> +
> >> +    while ( size-- )
> >> +        r = (r << 32) | be32_to_cpu(*(cell++));
> >> +    return r;
> >> +}
> >> +
> >> +static inline u64 dt_next_cell(int s, const __be32 **cellp)
> >> +{
> >> +    const __be32 *p = *cellp;
> >> +
> >> +    *cellp = p + s;
> >> +    return dt_read_number(p, s);
> >> +}
> >> +
> >> +typedef int (*device_tree_node_func)(const void *fdt,
> >> +                                     int node, const char *name, int depth,
> >> +                                     u32 address_cells, u32 size_cells,
> >> +                                     void *data);
> >> +
> >> +/**
> >> + * device_tree_for_each_node - iterate over all device tree sub-nodes
> >> + * @fdt: flat device tree.
> >> + * @node: parent node to start the search from
> >> + * @func: function to call for each sub-node.
> >> + * @data: data to pass to @func.
> >> + *
> >> + * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
> >> + *
> >> + * Returns 0 if all nodes were iterated over successfully.  If @func
> >> + * returns a value different from 0, that value is returned immediately.
> >> + */
> >> +int device_tree_for_each_node(const void *fdt, int node,
> >> +                              device_tree_node_func func,
> >> +                              void *data);
> >> +
> >>  typedef enum {
> >>      BOOTMOD_XEN,
> >>      BOOTMOD_FDT,
> >> @@ -246,4 +292,20 @@ static inline struct membanks *membanks_xzalloc(unsigned int nr,
> >>      return banks;
> >>  }
> >>
> >> +/*
> >> + * Interpret the property `prop_name` of `node` as a u32.
> >> + *
> >> + * Returns the property value on success; otherwise returns `dflt`.
> >> + */
> >> +uint32_t device_tree_get_u32(const void *fdt, int node,
> >> +                             const char *prop_name, uint32_t dflt);
> >
> > Suggest using `dt_` prefix (or any other good prefix) for all functions
> > in this header for consistency: e.g. there's dt_read_number() but also
> > device_tree_get_u32().
> 
> I'd be quite happy with an fdt_ prefix, to clearly show they relate to FDTs.

+1

> 
> But I didn't want to do that right away because it would obscure the strict code
> motion that's going on.

Got it!

> 
> >
> >> +
> >> +/*
> >> + * Interpret the property `prop_name` of `node` as a "reg".
> >> + *
> >> + * Returns outputs in `start` and `size`.
> >> + */
> >> +void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> >> +                         uint32_t size_cells, paddr_t *start, paddr_t *size);
> >> +
> >>  #endif /* XEN_BOOTFDT_H */
> >> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> >> index 6dc1fb5159..0a22b1ba1d 100644
> >> --- a/xen/include/xen/device_tree.h
> >> +++ b/xen/include/xen/device_tree.h
> >> @@ -10,6 +10,7 @@
> >>  #ifndef __XEN_DEVICE_TREE_H__
> >>  #define __XEN_DEVICE_TREE_H__
> >>
> >> +#include <xen/bootfdt.h>
> >>  #include <xen/byteorder.h>
> >>
> >>  #include <asm/device.h>
> >> @@ -22,8 +23,6 @@
> >>  #include <xen/list.h>
> >>  #include <xen/rwlock.h>
> >>
> >> -#define DEVICE_TREE_MAX_DEPTH 16
> >> -
> >>  /*
> >>   * Struct used for matching a device
> >>   */
> >> @@ -164,17 +163,8 @@ struct dt_raw_irq {
> >>      u32 specifier[DT_MAX_IRQ_SPEC];
> >>  };
> >>
> >> -typedef int (*device_tree_node_func)(const void *fdt,
> >> -                                     int node, const char *name, int depth,
> >> -                                     u32 address_cells, u32 size_cells,
> >> -                                     void *data);
> >> -
> >>  extern const void *device_tree_flattened;
> >>
> >> -int device_tree_for_each_node(const void *fdt, int node,
> >> -                              device_tree_node_func func,
> >> -                              void *data);
> >> -
> >>  /**
> >>   * dt_unflatten_host_device_tree - Unflatten the host device tree
> >>   *
> >> @@ -245,10 +235,6 @@ void intc_dt_preinit(void);
> >>  #define dt_node_cmp(s1, s2) strcasecmp((s1), (s2))
> >>  #define dt_compat_cmp(s1, s2) strcasecmp((s1), (s2))
> >>
> >> -/* Default #address and #size cells */
> >> -#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> >> -#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> >> -
> >>  #define dt_for_each_property_node(dn, pp)                   \
> >>      for ( pp = (dn)->properties; (pp) != NULL; pp = (pp)->next )
> >>
> >> @@ -258,16 +244,6 @@ void intc_dt_preinit(void);
> >>  #define dt_for_each_child_node(dt, dn)                      \
> >>      for ( dn = (dt)->child; (dn) != NULL; dn = (dn)->sibling )
> >>
> >> -/* Helper to read a big number; size is in cells (not bytes) */
> >> -static inline u64 dt_read_number(const __be32 *cell, int size)
> >> -{
> >> -    u64 r = 0;
> >> -
> >> -    while ( size-- )
> >> -        r = (r << 32) | be32_to_cpu(*(cell++));
> >> -    return r;
> >> -}
> >> -
> >>  /* Wrapper for dt_read_number() to return paddr_t (instead of uint64_t) */
> >>  static inline paddr_t dt_read_paddr(const __be32 *cell, int size)
> >>  {
> >> @@ -307,14 +283,6 @@ static inline int dt_size_to_cells(int bytes)
> >>      return (bytes / sizeof(u32));
> >>  }
> >>
> >> -static inline u64 dt_next_cell(int s, const __be32 **cellp)
> >> -{
> >> -    const __be32 *p = *cellp;
> >> -
> >> -    *cellp = p + s;
> >> -    return dt_read_number(p, s);
> >> -}
> >> -
> >>  static inline const char *dt_node_full_name(const struct dt_device_node *np)
> >>  {
> >>      return (np && np->full_name) ? np->full_name : "<no-node>";
> >> --
> >> 2.43.0
> >>
> >>
> 

Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h

[Stefano Stabellini]

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> Part of an unpicking process to extract bootfdt contents independent of bootinfo
> to a separate file for x86 to take.
> 
> Move functions required for early FDT parsing from device_tree.h and arm's
> setup.h onto bootfdt.h
> 
> Declaration motion only. Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
> ---
>  xen/arch/arm/include/asm/setup.h |  6 ----
>  xen/include/xen/bootfdt.h        | 62 ++++++++++++++++++++++++++++++++
>  xen/include/xen/device_tree.h    | 34 +-----------------
>  3 files changed, 63 insertions(+), 39 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
> index 0f9e531a34..32308837a9 100644
> --- a/xen/arch/arm/include/asm/setup.h
> +++ b/xen/arch/arm/include/asm/setup.h
> @@ -55,12 +55,6 @@ void setup_mm(void);
>  extern uint32_t hyp_traps_vector[];
>  void init_traps(void);
>  
> -void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> -                         uint32_t size_cells, paddr_t *start, paddr_t *size);
> -
> -u32 device_tree_get_u32(const void *fdt, int node,
> -                        const char *prop_name, u32 dflt);
> -
>  int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt,
>                    struct rangeset *iomem_ranges, struct rangeset *irq_ranges);
>  
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index fa65e8fcf4..079259c719 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -2,6 +2,7 @@
>  #ifndef XEN_BOOTFDT_H
>  #define XEN_BOOTFDT_H
>  
> +#include <xen/byteorder.h>
>  #include <xen/types.h>
>  #include <xen/kernel.h>
>  #include <xen/macros.h>
> @@ -16,8 +17,53 @@
>  #define NR_MEM_BANKS 256
>  #define NR_SHMEM_BANKS 32
>  
> +/* Default #address and #size cells */
> +#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> +#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> +
>  #define MAX_MODULES 32 /* Current maximum useful modules */
>  
> +#define DEVICE_TREE_MAX_DEPTH 16
> +
> +/* Helper to read a big number; size is in cells (not bytes) */
> +static inline u64 dt_read_number(const __be32 *cell, int size)
> +{
> +    u64 r = 0;
> +
> +    while ( size-- )
> +        r = (r << 32) | be32_to_cpu(*(cell++));
> +    return r;
> +}
> +
> +static inline u64 dt_next_cell(int s, const __be32 **cellp)
> +{
> +    const __be32 *p = *cellp;
> +
> +    *cellp = p + s;
> +    return dt_read_number(p, s);
> +}
> +
> +typedef int (*device_tree_node_func)(const void *fdt,
> +                                     int node, const char *name, int depth,
> +                                     u32 address_cells, u32 size_cells,
> +                                     void *data);
> +
> +/**
> + * device_tree_for_each_node - iterate over all device tree sub-nodes
> + * @fdt: flat device tree.
> + * @node: parent node to start the search from
> + * @func: function to call for each sub-node.
> + * @data: data to pass to @func.
> + *
> + * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
> + *
> + * Returns 0 if all nodes were iterated over successfully.  If @func
> + * returns a value different from 0, that value is returned immediately.
> + */
> +int device_tree_for_each_node(const void *fdt, int node,
> +                              device_tree_node_func func,
> +                              void *data);
> +
>  typedef enum {
>      BOOTMOD_XEN,
>      BOOTMOD_FDT,
> @@ -246,4 +292,20 @@ static inline struct membanks *membanks_xzalloc(unsigned int nr,
>      return banks;
>  }
>  
> +/*
> + * Interpret the property `prop_name` of `node` as a u32.
> + *
> + * Returns the property value on success; otherwise returns `dflt`.
> + */
> +uint32_t device_tree_get_u32(const void *fdt, int node,
> +                             const char *prop_name, uint32_t dflt);

The u32->uint32_t change is fine by me but you also need to change the
implementation otherwise we are going to get a MISRA error declaration
!= definition.

I'll take this opportunity to suggest you scan this series through
MISRA.


> +/*
> + * Interpret the property `prop_name` of `node` as a "reg".
> + *
> + * Returns outputs in `start` and `size`.
> + */
> +void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> +                         uint32_t size_cells, paddr_t *start, paddr_t *size);
> +
>  #endif /* XEN_BOOTFDT_H */
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 6dc1fb5159..0a22b1ba1d 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -10,6 +10,7 @@
>  #ifndef __XEN_DEVICE_TREE_H__
>  #define __XEN_DEVICE_TREE_H__
>  
> +#include <xen/bootfdt.h>
>  #include <xen/byteorder.h>
>  
>  #include <asm/device.h>
> @@ -22,8 +23,6 @@
>  #include <xen/list.h>
>  #include <xen/rwlock.h>
>  
> -#define DEVICE_TREE_MAX_DEPTH 16
> -
>  /*
>   * Struct used for matching a device
>   */
> @@ -164,17 +163,8 @@ struct dt_raw_irq {
>      u32 specifier[DT_MAX_IRQ_SPEC];
>  };
>  
> -typedef int (*device_tree_node_func)(const void *fdt,
> -                                     int node, const char *name, int depth,
> -                                     u32 address_cells, u32 size_cells,
> -                                     void *data);
> -
>  extern const void *device_tree_flattened;
>  
> -int device_tree_for_each_node(const void *fdt, int node,
> -                              device_tree_node_func func,
> -                              void *data);
> -
>  /**
>   * dt_unflatten_host_device_tree - Unflatten the host device tree
>   *
> @@ -245,10 +235,6 @@ void intc_dt_preinit(void);
>  #define dt_node_cmp(s1, s2) strcasecmp((s1), (s2))
>  #define dt_compat_cmp(s1, s2) strcasecmp((s1), (s2))
>  
> -/* Default #address and #size cells */
> -#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> -#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> -
>  #define dt_for_each_property_node(dn, pp)                   \
>      for ( pp = (dn)->properties; (pp) != NULL; pp = (pp)->next )
>  
> @@ -258,16 +244,6 @@ void intc_dt_preinit(void);
>  #define dt_for_each_child_node(dt, dn)                      \
>      for ( dn = (dt)->child; (dn) != NULL; dn = (dn)->sibling )
>  
> -/* Helper to read a big number; size is in cells (not bytes) */
> -static inline u64 dt_read_number(const __be32 *cell, int size)
> -{
> -    u64 r = 0;
> -
> -    while ( size-- )
> -        r = (r << 32) | be32_to_cpu(*(cell++));
> -    return r;
> -}
> -
>  /* Wrapper for dt_read_number() to return paddr_t (instead of uint64_t) */
>  static inline paddr_t dt_read_paddr(const __be32 *cell, int size)
>  {
> @@ -307,14 +283,6 @@ static inline int dt_size_to_cells(int bytes)
>      return (bytes / sizeof(u32));
>  }
>  
> -static inline u64 dt_next_cell(int s, const __be32 **cellp)
> -{
> -    const __be32 *p = *cellp;
> -
> -    *cellp = p + s;
> -    return dt_read_number(p, s);
> -}
> -
>  static inline const char *dt_node_full_name(const struct dt_device_node *np)
>  {
>      return (np && np->full_name) ? np->full_name : "<no-node>";
> -- 
> 2.43.0
> 

Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> Part of an unpicking process to extract bootfdt contents independent of bootinfo
> to a separate file for x86 to take.
> 
> Move functions required for early FDT parsing from device_tree.h and arm's
> setup.h onto bootfdt.h
> 
> Declaration motion only. Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>

I get this build error:

  CC      common/sysctl.o
In file included from ./include/xen/fdt-kernel.h:11,
                 from ./arch/x86/include/asm/bootinfo.h:12,
                 from arch/x86/hvm/dom0_build.c:19:
./include/xen/device_tree.h:112:19: error: field ‘dev’ has incomplete type
  112 |     struct device dev;
      |                   ^~~

Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h

[Daniel P. Smith]

On 5/30/25 08:02, Alejandro Vallejo wrote:
> Part of an unpicking process to extract bootfdt contents independent of bootinfo
> to a separate file for x86 to take.
> 
> Move functions required for early FDT parsing from device_tree.h and arm's
> setup.h onto bootfdt.h
> 
> Declaration motion only. Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
> ---
>   xen/arch/arm/include/asm/setup.h |  6 ----
>   xen/include/xen/bootfdt.h        | 62 ++++++++++++++++++++++++++++++++
>   xen/include/xen/device_tree.h    | 34 +-----------------
>   3 files changed, 63 insertions(+), 39 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
> index 0f9e531a34..32308837a9 100644
> --- a/xen/arch/arm/include/asm/setup.h
> +++ b/xen/arch/arm/include/asm/setup.h
> @@ -55,12 +55,6 @@ void setup_mm(void);
>   extern uint32_t hyp_traps_vector[];
>   void init_traps(void);
>   
> -void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> -                         uint32_t size_cells, paddr_t *start, paddr_t *size);
> -
> -u32 device_tree_get_u32(const void *fdt, int node,
> -                        const char *prop_name, u32 dflt);
> -
>   int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt,
>                     struct rangeset *iomem_ranges, struct rangeset *irq_ranges);
>   
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index fa65e8fcf4..079259c719 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -2,6 +2,7 @@
>   #ifndef XEN_BOOTFDT_H
>   #define XEN_BOOTFDT_H
>   
> +#include <xen/byteorder.h>
>   #include <xen/types.h>
>   #include <xen/kernel.h>
>   #include <xen/macros.h>
> @@ -16,8 +17,53 @@
>   #define NR_MEM_BANKS 256
>   #define NR_SHMEM_BANKS 32
>   
> +/* Default #address and #size cells */
> +#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> +#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> +
>   #define MAX_MODULES 32 /* Current maximum useful modules */
>   
> +#define DEVICE_TREE_MAX_DEPTH 16
> +
> +/* Helper to read a big number; size is in cells (not bytes) */
> +static inline u64 dt_read_number(const __be32 *cell, int size)
> +{
> +    u64 r = 0;
> +
> +    while ( size-- )
> +        r = (r << 32) | be32_to_cpu(*(cell++));
> +    return r;
> +}

I know you are trying to keep code changes to a minimal but let's not 
allow poorly constructed logic like this to continue to persist. This is 
an unbounded, arbitrary read function that is feed parameters via 
externally input. The DT spec declares only two number types for a 
property, u32 and u64, see Table 2.3 in Section 2.2.4. There is no 
reason to have an unbounded, arbitrary read function lying around 
waiting to be leveraged in exploitation.


> +static inline u64 dt_next_cell(int s, const __be32 **cellp)
> +{
> +    const __be32 *p = *cellp;
> +
> +    *cellp = p + s;
> +    return dt_read_number(p, s);
> +}
> +
> +typedef int (*device_tree_node_func)(const void *fdt,
> +                                     int node, const char *name, int depth,
> +                                     u32 address_cells, u32 size_cells,
> +                                     void *data);
> +
> +/**
> + * device_tree_for_each_node - iterate over all device tree sub-nodes
> + * @fdt: flat device tree.
> + * @node: parent node to start the search from
> + * @func: function to call for each sub-node.
> + * @data: data to pass to @func.
> + *
> + * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
> + *
> + * Returns 0 if all nodes were iterated over successfully.  If @func
> + * returns a value different from 0, that value is returned immediately.
> + */
> +int device_tree_for_each_node(const void *fdt, int node,
> +                              device_tree_node_func func,
> +                              void *data);
> +
>   typedef enum {
>       BOOTMOD_XEN,
>       BOOTMOD_FDT,
> @@ -246,4 +292,20 @@ static inline struct membanks *membanks_xzalloc(unsigned int nr,
>       return banks;
>   }
>   
> +/*
> + * Interpret the property `prop_name` of `node` as a u32.
> + *
> + * Returns the property value on success; otherwise returns `dflt`.
> + */
> +uint32_t device_tree_get_u32(const void *fdt, int node,
> +                             const char *prop_name, uint32_t dflt);
> +
> +/*
> + * Interpret the property `prop_name` of `node` as a "reg".
> + *
> + * Returns outputs in `start` and `size`.
> + */
> +void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> +                         uint32_t size_cells, paddr_t *start, paddr_t *size);
> +
>   #endif /* XEN_BOOTFDT_H */
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 6dc1fb5159..0a22b1ba1d 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -10,6 +10,7 @@
>   #ifndef __XEN_DEVICE_TREE_H__
>   #define __XEN_DEVICE_TREE_H__
>   
> +#include <xen/bootfdt.h>
>   #include <xen/byteorder.h>
>   
>   #include <asm/device.h>
> @@ -22,8 +23,6 @@
>   #include <xen/list.h>
>   #include <xen/rwlock.h>
>   
> -#define DEVICE_TREE_MAX_DEPTH 16
> -
>   /*
>    * Struct used for matching a device
>    */
> @@ -164,17 +163,8 @@ struct dt_raw_irq {
>       u32 specifier[DT_MAX_IRQ_SPEC];
>   };
>   
> -typedef int (*device_tree_node_func)(const void *fdt,
> -                                     int node, const char *name, int depth,
> -                                     u32 address_cells, u32 size_cells,
> -                                     void *data);
> -
>   extern const void *device_tree_flattened;
>   
> -int device_tree_for_each_node(const void *fdt, int node,
> -                              device_tree_node_func func,
> -                              void *data);
> -
>   /**
>    * dt_unflatten_host_device_tree - Unflatten the host device tree
>    *
> @@ -245,10 +235,6 @@ void intc_dt_preinit(void);
>   #define dt_node_cmp(s1, s2) strcasecmp((s1), (s2))
>   #define dt_compat_cmp(s1, s2) strcasecmp((s1), (s2))
>   
> -/* Default #address and #size cells */
> -#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> -#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> -
>   #define dt_for_each_property_node(dn, pp)                   \
>       for ( pp = (dn)->properties; (pp) != NULL; pp = (pp)->next )
>   
> @@ -258,16 +244,6 @@ void intc_dt_preinit(void);
>   #define dt_for_each_child_node(dt, dn)                      \
>       for ( dn = (dt)->child; (dn) != NULL; dn = (dn)->sibling )
>   
> -/* Helper to read a big number; size is in cells (not bytes) */
> -static inline u64 dt_read_number(const __be32 *cell, int size)
> -{
> -    u64 r = 0;
> -
> -    while ( size-- )
> -        r = (r << 32) | be32_to_cpu(*(cell++));
> -    return r;
> -}
> -
>   /* Wrapper for dt_read_number() to return paddr_t (instead of uint64_t) */
>   static inline paddr_t dt_read_paddr(const __be32 *cell, int size)
>   {
> @@ -307,14 +283,6 @@ static inline int dt_size_to_cells(int bytes)
>       return (bytes / sizeof(u32));
>   }
>   
> -static inline u64 dt_next_cell(int s, const __be32 **cellp)
> -{
> -    const __be32 *p = *cellp;
> -
> -    *cellp = p + s;
> -    return dt_read_number(p, s);
> -}
> -
>   static inline const char *dt_node_full_name(const struct dt_device_node *np)
>   {
>       return (np && np->full_name) ? np->full_name : "<no-node>";

Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h

[Alejandro Vallejo]

On Mon Jun 2, 2025 at 10:25 PM CEST, Daniel P. Smith wrote:
>> +/* Helper to read a big number; size is in cells (not bytes) */
>> +static inline u64 dt_read_number(const __be32 *cell, int size)
>> +{
>> +    u64 r = 0;
>> +
>> +    while ( size-- )
>> +        r = (r << 32) | be32_to_cpu(*(cell++));
>> +    return r;
>> +}
>
> I know you are trying to keep code changes to a minimal but let's not 
> allow poorly constructed logic like this to continue to persist. This is 
> an unbounded, arbitrary read function that is feed parameters via 
> externally input. The DT spec declares only two number types for a 
> property, u32 and u64, see Table 2.3 in Section 2.2.4. There is no 
> reason to have an unbounded, arbitrary read function lying around 
> waiting to be leveraged in exploitation.

Seeing how it's a big lump of code motion, I really don't want to play games
or I will myself lose track of what I changed and what I didn't.

While I agree it should probably be a switch statement (or factored away
altogether), this isn't the place for it.

Cheers,
Alejandro

Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h

[Stefano Stabellini]

On Thu, 5 Jun 2025, Alejandro Vallejo wrote:
> On Mon Jun 2, 2025 at 10:25 PM CEST, Daniel P. Smith wrote:
> >> +/* Helper to read a big number; size is in cells (not bytes) */
> >> +static inline u64 dt_read_number(const __be32 *cell, int size)
> >> +{
> >> +    u64 r = 0;
> >> +
> >> +    while ( size-- )
> >> +        r = (r << 32) | be32_to_cpu(*(cell++));
> >> +    return r;
> >> +}
> >
> > I know you are trying to keep code changes to a minimal but let's not 
> > allow poorly constructed logic like this to continue to persist. This is 
> > an unbounded, arbitrary read function that is feed parameters via 
> > externally input. The DT spec declares only two number types for a 
> > property, u32 and u64, see Table 2.3 in Section 2.2.4. There is no 
> > reason to have an unbounded, arbitrary read function lying around 
> > waiting to be leveraged in exploitation.
> 
> Seeing how it's a big lump of code motion, I really don't want to play games
> or I will myself lose track of what I changed and what I didn't.
> 
> While I agree it should probably be a switch statement (or factored away
> altogether), this isn't the place for it.

The improvement suggested by Daniel should be in a separate patch from
the code movement to make it easier to review, but it can still be part
of the patch series.

Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h

[Daniel P. Smith]

On 6/5/25 14:03, Alejandro Vallejo wrote:
> On Mon Jun 2, 2025 at 10:25 PM CEST, Daniel P. Smith wrote:
>>> +/* Helper to read a big number; size is in cells (not bytes) */
>>> +static inline u64 dt_read_number(const __be32 *cell, int size)
>>> +{
>>> +    u64 r = 0;
>>> +
>>> +    while ( size-- )
>>> +        r = (r << 32) | be32_to_cpu(*(cell++));
>>> +    return r;
>>> +}
>>
>> I know you are trying to keep code changes to a minimal but let's not
>> allow poorly constructed logic like this to continue to persist. This is
>> an unbounded, arbitrary read function that is feed parameters via
>> externally input. The DT spec declares only two number types for a
>> property, u32 and u64, see Table 2.3 in Section 2.2.4. There is no
>> reason to have an unbounded, arbitrary read function lying around
>> waiting to be leveraged in exploitation.
> 
> Seeing how it's a big lump of code motion, I really don't want to play games
> or I will myself lose track of what I changed and what I didn't.

You could have a preliminary commit before this one that removes a 
clearly vulnerable code, and then this commit can move it. Or reverse it 
and do the code move and fix it.

> While I agree it should probably be a switch statement (or factored away
> altogether), this isn't the place for it.

All due respect, but leaving code that is clearly a sitting 
vulnerability mine is not really a great choice.

V/r,
dps

[PATCH 13/19] xen/dt: Move bootinfo functions to a new bootinfo.h

[Alejandro Vallejo]

Part of an unpicking process to extract bootfdt contents independent of
bootinfo to a separate file for x86 to take.

With this, bootfdt.h can be cleanly included from x86. A later patch
extracts the definitions so the functions may be called too.

Not a functional change.

Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
 xen/arch/arm/domain_build.c             |   1 +
 xen/arch/arm/mmu/mm.c                   |   1 +
 xen/arch/riscv/mm.c                     |   2 +-
 xen/arch/riscv/setup.c                  |   2 +-
 xen/common/device-tree/bootfdt.c        |   1 +
 xen/common/device-tree/bootinfo.c       |   2 +-
 xen/common/device-tree/dom0less-build.c |   2 +-
 xen/common/device-tree/domain-build.c   |   2 +-
 xen/common/device-tree/kernel.c         |   2 +-
 xen/include/xen/bootfdt.h               | 206 -----------------------
 xen/include/xen/bootinfo.h              | 212 ++++++++++++++++++++++++
 xen/include/xen/device_tree.h           |   2 +-
 xen/include/xen/fdt-domain-build.h      |   2 +-
 xen/include/xen/fdt-kernel.h            |   2 +-
 14 files changed, 224 insertions(+), 215 deletions(-)
 create mode 100644 xen/include/xen/bootinfo.h

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 11cc03e5db..c53da76682 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1,5 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 #include <xen/init.h>
+#include <xen/bootinfo.h>
 #include <xen/compile.h>
 #include <xen/fdt-domain-build.h>
 #include <xen/fdt-kernel.h>
diff --git a/xen/arch/arm/mmu/mm.c b/xen/arch/arm/mmu/mm.c
index 9c50479c63..77f82757bb 100644
--- a/xen/arch/arm/mmu/mm.c
+++ b/xen/arch/arm/mmu/mm.c
@@ -1,5 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-or-later */
 
+#include <xen/bootinfo.h>
 #include <xen/init.h>
 #include <xen/lib.h>
 #include <xen/macros.h>
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index d3ece9f132..040db73d00 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#include <xen/bootfdt.h>
+#include <xen/bootinfo.h>
 #include <xen/bug.h>
 #include <xen/compiler.h>
 #include <xen/init.h>
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 4e416f6e44..0a2d0dc1eb 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -2,7 +2,7 @@
 
 #include <xen/acpi.h>
 #include <xen/bug.h>
-#include <xen/bootfdt.h>
+#include <xen/bootinfo.h>
 #include <xen/compile.h>
 #include <xen/device_tree.h>
 #include <xen/init.h>
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index 529c91e603..fb4ac06390 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -6,6 +6,7 @@
  */
 
 #include <xen/bootfdt.h>
+#include <xen/bootinfo.h>
 #include <xen/device_tree.h>
 #include <xen/efi.h>
 #include <xen/init.h>
diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c
index 717cfa0962..69491bdb0b 100644
--- a/xen/common/device-tree/bootinfo.c
+++ b/xen/common/device-tree/bootinfo.c
@@ -10,7 +10,7 @@
  */
 
 #include <xen/acpi.h>
-#include <xen/bootfdt.h>
+#include <xen/bootinfo.h>
 #include <xen/bug.h>
 #include <xen/device_tree.h>
 #include <xen/init.h>
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 39cb2cd5c7..c798807560 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#include <xen/bootfdt.h>
+#include <xen/bootinfo.h>
 #include <xen/device_tree.h>
 #include <xen/domain.h>
 #include <xen/domain_page.h>
diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
index 6b8b8d7cac..e5d34dd89d 100644
--- a/xen/common/device-tree/domain-build.c
+++ b/xen/common/device-tree/domain-build.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#include <xen/bootfdt.h>
+#include <xen/bootinfo.h>
 #include <xen/fdt-domain-build.h>
 #include <xen/init.h>
 #include <xen/lib.h>
diff --git a/xen/common/device-tree/kernel.c b/xen/common/device-tree/kernel.c
index cb04cd9d50..d02440cc2d 100644
--- a/xen/common/device-tree/kernel.c
+++ b/xen/common/device-tree/kernel.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#include <xen/bootfdt.h>
+#include <xen/bootinfo.h>
 #include <xen/device_tree.h>
 #include <xen/fdt-kernel.h>
 #include <xen/errno.h>
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 079259c719..766956e102 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -4,9 +4,6 @@
 
 #include <xen/byteorder.h>
 #include <xen/types.h>
-#include <xen/kernel.h>
-#include <xen/macros.h>
-#include <xen/xmalloc.h>
 
 #if __has_include(<asm/bootfdt.h>)
 #include <asm/bootfdt.h>
@@ -14,15 +11,10 @@
 
 #define MIN_FDT_ALIGN 8
 
-#define NR_MEM_BANKS 256
-#define NR_SHMEM_BANKS 32
-
 /* Default #address and #size cells */
 #define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
 #define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
 
-#define MAX_MODULES 32 /* Current maximum useful modules */
-
 #define DEVICE_TREE_MAX_DEPTH 16
 
 /* Helper to read a big number; size is in cells (not bytes) */
@@ -75,77 +67,6 @@ typedef enum {
     BOOTMOD_UNKNOWN
 }  bootmodule_kind;
 
-enum membank_type {
-    /*
-     * The MEMBANK_DEFAULT type refers to either reserved memory for the
-     * device/firmware (when the bank is in 'reserved_mem') or any RAM (when
-     * the bank is in 'mem').
-     */
-    MEMBANK_DEFAULT,
-    /*
-     * The MEMBANK_STATIC_DOMAIN type is used to indicate whether the memory
-     * bank is bound to a static Xen domain. It is only valid when the bank
-     * is in reserved_mem.
-     */
-    MEMBANK_STATIC_DOMAIN,
-    /*
-     * The MEMBANK_STATIC_HEAP type is used to indicate whether the memory
-     * bank is reserved as static heap. It is only valid when the bank is
-     * in reserved_mem.
-     */
-    MEMBANK_STATIC_HEAP,
-    /*
-     * The MEMBANK_FDT_RESVMEM type is used to indicate whether the memory
-     * bank is from the FDT reserve map.
-     */
-    MEMBANK_FDT_RESVMEM,
-};
-
-enum region_type {
-    MEMORY,
-    RESERVED_MEMORY,
-    STATIC_SHARED_MEMORY
-};
-
-/* Indicates the maximum number of characters(\0 included) for shm_id */
-#define MAX_SHM_ID_LENGTH 16
-
-struct shmem_membank_extra {
-    char shm_id[MAX_SHM_ID_LENGTH];
-    unsigned int nr_shm_borrowers;
-};
-
-struct membank {
-    paddr_t start;
-    paddr_t size;
-    union {
-        enum membank_type type;
-#ifdef CONFIG_STATIC_SHM
-        struct shmem_membank_extra *shmem_extra;
-#endif
-    };
-};
-
-struct membanks {
-    __struct_group(membanks_hdr, common, ,
-        unsigned int nr_banks;
-        unsigned int max_banks;
-        enum region_type type;
-    );
-    struct membank bank[];
-};
-
-struct meminfo {
-    struct membanks_hdr common;
-    struct membank bank[NR_MEM_BANKS];
-};
-
-struct shared_meminfo {
-    struct membanks_hdr common;
-    struct membank bank[NR_SHMEM_BANKS];
-    struct shmem_membank_extra extra[NR_SHMEM_BANKS];
-};
-
 /*
  * The domU flag is set for kernels and ramdisks of "xen,domain" nodes.
  * The purpose of the domU flag is to avoid getting confused in
@@ -165,133 +86,6 @@ struct bootmodule {
 #endif
 };
 
-/* DT_MAX_NAME is the node name max length according the DT spec */
-#define DT_MAX_NAME 41
-struct bootcmdline {
-    bootmodule_kind kind;
-    bool domU;
-    paddr_t start;
-    char dt_name[DT_MAX_NAME];
-    char cmdline[BOOTMOD_MAX_CMDLINE];
-};
-
-struct bootmodules {
-    int nr_mods;
-    struct bootmodule module[MAX_MODULES];
-};
-
-struct bootcmdlines {
-    unsigned int nr_mods;
-    struct bootcmdline cmdline[MAX_MODULES];
-};
-
-struct bootinfo {
-    struct meminfo mem;
-    /* The reserved regions are only used when booting using Device-Tree */
-    struct meminfo reserved_mem;
-    struct bootmodules modules;
-    struct bootcmdlines cmdlines;
-#ifdef CONFIG_ACPI
-    struct meminfo acpi;
-#endif
-#ifdef CONFIG_STATIC_SHM
-    struct shared_meminfo shmem;
-#endif
-};
-
-#ifdef CONFIG_ACPI
-#define BOOTINFO_ACPI_INIT                          \
-    .acpi.common.max_banks = NR_MEM_BANKS,          \
-    .acpi.common.type = MEMORY,
-#else
-#define BOOTINFO_ACPI_INIT
-#endif
-
-#ifdef CONFIG_STATIC_SHM
-#define BOOTINFO_SHMEM_INIT                         \
-    .shmem.common.max_banks = NR_SHMEM_BANKS,       \
-    .shmem.common.type = STATIC_SHARED_MEMORY,
-#else
-#define BOOTINFO_SHMEM_INIT
-#endif
-
-#define BOOTINFO_INIT                               \
-{                                                   \
-    .mem.common.max_banks = NR_MEM_BANKS,           \
-    .mem.common.type = MEMORY,                      \
-    .reserved_mem.common.max_banks = NR_MEM_BANKS,  \
-    .reserved_mem.common.type = RESERVED_MEMORY,    \
-    BOOTINFO_ACPI_INIT                              \
-    BOOTINFO_SHMEM_INIT                             \
-}
-
-extern struct bootinfo bootinfo;
-
-bool check_reserved_regions_overlap(paddr_t region_start,
-                                    paddr_t region_size,
-                                    bool allow_memreserve_overlap);
-
-struct bootmodule *add_boot_module(bootmodule_kind kind,
-                                   paddr_t start, paddr_t size, bool domU);
-struct bootmodule *boot_module_find_by_kind(bootmodule_kind kind);
-struct bootmodule * boot_module_find_by_addr_and_kind(bootmodule_kind kind,
-                                                             paddr_t start);
-void add_boot_cmdline(const char *name, const char *cmdline,
-                      bootmodule_kind kind, paddr_t start, bool domU);
-struct bootcmdline *boot_cmdline_find_by_kind(bootmodule_kind kind);
-struct bootcmdline * boot_cmdline_find_by_name(const char *name);
-const char *boot_module_kind_as_string(bootmodule_kind kind);
-
-void populate_boot_allocator(void);
-
-size_t boot_fdt_info(const void *fdt, paddr_t paddr);
-
-const char *boot_fdt_cmdline(const void *fdt);
-
-static inline struct membanks *bootinfo_get_reserved_mem(void)
-{
-    return container_of(&bootinfo.reserved_mem.common, struct membanks, common);
-}
-
-static inline struct membanks *bootinfo_get_mem(void)
-{
-    return container_of(&bootinfo.mem.common, struct membanks, common);
-}
-
-#ifdef CONFIG_ACPI
-static inline struct membanks *bootinfo_get_acpi(void)
-{
-    return container_of(&bootinfo.acpi.common, struct membanks, common);
-}
-#endif
-
-#ifdef CONFIG_STATIC_SHM
-static inline struct membanks *bootinfo_get_shmem(void)
-{
-    return container_of(&bootinfo.shmem.common, struct membanks, common);
-}
-
-static inline struct shmem_membank_extra *bootinfo_get_shmem_extra(void)
-{
-    return bootinfo.shmem.extra;
-}
-#endif
-
-static inline struct membanks *membanks_xzalloc(unsigned int nr,
-                                                enum region_type type)
-{
-    struct membanks *banks = xzalloc_flex_struct(struct membanks, bank, nr);
-
-    if ( !banks )
-        goto out;
-
-    banks->max_banks = nr;
-    banks->type = type;
-
- out:
-    return banks;
-}
-
 /*
  * Interpret the property `prop_name` of `node` as a u32.
  *
diff --git a/xen/include/xen/bootinfo.h b/xen/include/xen/bootinfo.h
new file mode 100644
index 0000000000..bf7516ec1f
--- /dev/null
+++ b/xen/include/xen/bootinfo.h
@@ -0,0 +1,212 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef XEN_BOOTINFO_H
+#define XEN_BOOTINFO_H
+
+#include <xen/bootfdt.h>
+#include <xen/kernel.h>
+#include <xen/macros.h>
+#include <xen/xmalloc.h>
+
+#define NR_MEM_BANKS 256
+#define NR_SHMEM_BANKS 32
+
+#define MAX_MODULES 32 /* Current maximum useful modules */
+
+enum membank_type {
+    /*
+     * The MEMBANK_DEFAULT type refers to either reserved memory for the
+     * device/firmware (when the bank is in 'reserved_mem') or any RAM (when
+     * the bank is in 'mem').
+     */
+    MEMBANK_DEFAULT,
+    /*
+     * The MEMBANK_STATIC_DOMAIN type is used to indicate whether the memory
+     * bank is bound to a static Xen domain. It is only valid when the bank
+     * is in reserved_mem.
+     */
+    MEMBANK_STATIC_DOMAIN,
+    /*
+     * The MEMBANK_STATIC_HEAP type is used to indicate whether the memory
+     * bank is reserved as static heap. It is only valid when the bank is
+     * in reserved_mem.
+     */
+    MEMBANK_STATIC_HEAP,
+    /*
+     * The MEMBANK_FDT_RESVMEM type is used to indicate whether the memory
+     * bank is from the FDT reserve map.
+     */
+    MEMBANK_FDT_RESVMEM,
+};
+
+enum region_type {
+    MEMORY,
+    RESERVED_MEMORY,
+    STATIC_SHARED_MEMORY
+};
+
+/* Indicates the maximum number of characters(\0 included) for shm_id */
+#define MAX_SHM_ID_LENGTH 16
+
+struct shmem_membank_extra {
+    char shm_id[MAX_SHM_ID_LENGTH];
+    unsigned int nr_shm_borrowers;
+};
+
+struct membank {
+    paddr_t start;
+    paddr_t size;
+    union {
+        enum membank_type type;
+#ifdef CONFIG_STATIC_SHM
+        struct shmem_membank_extra *shmem_extra;
+#endif
+    };
+};
+
+struct membanks {
+    __struct_group(membanks_hdr, common, ,
+        unsigned int nr_banks;
+        unsigned int max_banks;
+        enum region_type type;
+    );
+    struct membank bank[];
+};
+
+struct meminfo {
+    struct membanks_hdr common;
+    struct membank bank[NR_MEM_BANKS];
+};
+
+struct shared_meminfo {
+    struct membanks_hdr common;
+    struct membank bank[NR_SHMEM_BANKS];
+    struct shmem_membank_extra extra[NR_SHMEM_BANKS];
+};
+
+/* DT_MAX_NAME is the node name max length according the DT spec */
+#define DT_MAX_NAME 41
+struct bootcmdline {
+    bootmodule_kind kind;
+    bool domU;
+    paddr_t start;
+    char dt_name[DT_MAX_NAME];
+    char cmdline[BOOTMOD_MAX_CMDLINE];
+};
+
+struct bootmodules {
+    int nr_mods;
+    struct bootmodule module[MAX_MODULES];
+};
+
+struct bootcmdlines {
+    unsigned int nr_mods;
+    struct bootcmdline cmdline[MAX_MODULES];
+};
+
+struct bootinfo {
+    struct meminfo mem;
+    /* The reserved regions are only used when booting using Device-Tree */
+    struct meminfo reserved_mem;
+    struct bootmodules modules;
+    struct bootcmdlines cmdlines;
+#ifdef CONFIG_ACPI
+    struct meminfo acpi;
+#endif
+#ifdef CONFIG_STATIC_SHM
+    struct shared_meminfo shmem;
+#endif
+};
+
+#ifdef CONFIG_ACPI
+#define BOOTINFO_ACPI_INIT                          \
+    .acpi.common.max_banks = NR_MEM_BANKS,          \
+    .acpi.common.type = MEMORY,
+#else
+#define BOOTINFO_ACPI_INIT
+#endif
+
+#ifdef CONFIG_STATIC_SHM
+#define BOOTINFO_SHMEM_INIT                         \
+    .shmem.common.max_banks = NR_SHMEM_BANKS,       \
+    .shmem.common.type = STATIC_SHARED_MEMORY,
+#else
+#define BOOTINFO_SHMEM_INIT
+#endif
+
+#define BOOTINFO_INIT                               \
+{                                                   \
+    .mem.common.max_banks = NR_MEM_BANKS,           \
+    .mem.common.type = MEMORY,                      \
+    .reserved_mem.common.max_banks = NR_MEM_BANKS,  \
+    .reserved_mem.common.type = RESERVED_MEMORY,    \
+    BOOTINFO_ACPI_INIT                              \
+    BOOTINFO_SHMEM_INIT                             \
+}
+
+extern struct bootinfo bootinfo;
+
+bool check_reserved_regions_overlap(paddr_t region_start,
+                                    paddr_t region_size,
+                                    bool allow_memreserve_overlap);
+
+struct bootmodule *add_boot_module(bootmodule_kind kind,
+                                   paddr_t start, paddr_t size, bool domU);
+struct bootmodule *boot_module_find_by_kind(bootmodule_kind kind);
+struct bootmodule * boot_module_find_by_addr_and_kind(bootmodule_kind kind,
+                                                             paddr_t start);
+void add_boot_cmdline(const char *name, const char *cmdline,
+                      bootmodule_kind kind, paddr_t start, bool domU);
+struct bootcmdline *boot_cmdline_find_by_kind(bootmodule_kind kind);
+struct bootcmdline * boot_cmdline_find_by_name(const char *name);
+const char *boot_module_kind_as_string(bootmodule_kind kind);
+
+void populate_boot_allocator(void);
+
+size_t boot_fdt_info(const void *fdt, paddr_t paddr);
+const char *boot_fdt_cmdline(const void *fdt);
+
+static inline struct membanks *bootinfo_get_reserved_mem(void)
+{
+    return container_of(&bootinfo.reserved_mem.common, struct membanks, common);
+}
+
+static inline struct membanks *bootinfo_get_mem(void)
+{
+    return container_of(&bootinfo.mem.common, struct membanks, common);
+}
+
+#ifdef CONFIG_ACPI
+static inline struct membanks *bootinfo_get_acpi(void)
+{
+    return container_of(&bootinfo.acpi.common, struct membanks, common);
+}
+#endif
+
+#ifdef CONFIG_STATIC_SHM
+static inline struct membanks *bootinfo_get_shmem(void)
+{
+    return container_of(&bootinfo.shmem.common, struct membanks, common);
+}
+
+static inline struct shmem_membank_extra *bootinfo_get_shmem_extra(void)
+{
+    return bootinfo.shmem.extra;
+}
+#endif
+
+static inline struct membanks *membanks_xzalloc(unsigned int nr,
+                                                enum region_type type)
+{
+    struct membanks *banks = xzalloc_flex_struct(struct membanks, bank, nr);
+
+    if ( !banks )
+        goto out;
+
+    banks->max_banks = nr;
+    banks->type = type;
+
+ out:
+    return banks;
+}
+
+#endif /* XEN_BOOTINFO_H */
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 0a22b1ba1d..7d1c8bc305 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -10,7 +10,7 @@
 #ifndef __XEN_DEVICE_TREE_H__
 #define __XEN_DEVICE_TREE_H__
 
-#include <xen/bootfdt.h>
+#include <xen/bootinfo.h>
 #include <xen/byteorder.h>
 
 #include <asm/device.h>
diff --git a/xen/include/xen/fdt-domain-build.h b/xen/include/xen/fdt-domain-build.h
index 45981dbec0..60565fdbf9 100644
--- a/xen/include/xen/fdt-domain-build.h
+++ b/xen/include/xen/fdt-domain-build.h
@@ -3,7 +3,7 @@
 #ifndef __XEN_FDT_DOMAIN_BUILD_H__
 #define __XEN_FDT_DOMAIN_BUILD_H__
 
-#include <xen/bootfdt.h>
+#include <xen/bootinfo.h>
 #include <xen/device_tree.h>
 #include <xen/fdt-kernel.h>
 #include <xen/mm.h>
diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
index 2f0ee42ebc..cb7ddc9807 100644
--- a/xen/include/xen/fdt-kernel.h
+++ b/xen/include/xen/fdt-kernel.h
@@ -7,7 +7,7 @@
 #ifndef __XEN_FDT_KERNEL_H__
 #define __XEN_FDT_KERNEL_H__
 
-#include <xen/bootfdt.h>
+#include <xen/bootinfo.h>
 #include <xen/device_tree.h>
 #include <xen/types.h>
 
-- 
2.43.0

Re: [PATCH 13/19] xen/dt: Move bootinfo functions to a new bootinfo.h

[Stefano Stabellini]

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> Part of an unpicking process to extract bootfdt contents independent of
> bootinfo to a separate file for x86 to take.
> 
> With this, bootfdt.h can be cleanly included from x86. A later patch
> extracts the definitions so the functions may be called too.
> 
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
> ---
>  xen/arch/arm/domain_build.c             |   1 +
>  xen/arch/arm/mmu/mm.c                   |   1 +
>  xen/arch/riscv/mm.c                     |   2 +-
>  xen/arch/riscv/setup.c                  |   2 +-
>  xen/common/device-tree/bootfdt.c        |   1 +
>  xen/common/device-tree/bootinfo.c       |   2 +-
>  xen/common/device-tree/dom0less-build.c |   2 +-
>  xen/common/device-tree/domain-build.c   |   2 +-
>  xen/common/device-tree/kernel.c         |   2 +-
>  xen/include/xen/bootfdt.h               | 206 -----------------------
>  xen/include/xen/bootinfo.h              | 212 ++++++++++++++++++++++++
>  xen/include/xen/device_tree.h           |   2 +-
>  xen/include/xen/fdt-domain-build.h      |   2 +-
>  xen/include/xen/fdt-kernel.h            |   2 +-
>  14 files changed, 224 insertions(+), 215 deletions(-)
>  create mode 100644 xen/include/xen/bootinfo.h
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 11cc03e5db..c53da76682 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1,5 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
>  #include <xen/init.h>
> +#include <xen/bootinfo.h>
>  #include <xen/compile.h>
>  #include <xen/fdt-domain-build.h>
>  #include <xen/fdt-kernel.h>
> diff --git a/xen/arch/arm/mmu/mm.c b/xen/arch/arm/mmu/mm.c
> index 9c50479c63..77f82757bb 100644
> --- a/xen/arch/arm/mmu/mm.c
> +++ b/xen/arch/arm/mmu/mm.c
> @@ -1,5 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0-or-later */
>  
> +#include <xen/bootinfo.h>
>  #include <xen/init.h>
>  #include <xen/lib.h>
>  #include <xen/macros.h>
> diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
> index d3ece9f132..040db73d00 100644
> --- a/xen/arch/riscv/mm.c
> +++ b/xen/arch/riscv/mm.c
> @@ -1,6 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
>  
> -#include <xen/bootfdt.h>
> +#include <xen/bootinfo.h>
>  #include <xen/bug.h>
>  #include <xen/compiler.h>
>  #include <xen/init.h>
> diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
> index 4e416f6e44..0a2d0dc1eb 100644
> --- a/xen/arch/riscv/setup.c
> +++ b/xen/arch/riscv/setup.c
> @@ -2,7 +2,7 @@
>  
>  #include <xen/acpi.h>
>  #include <xen/bug.h>
> -#include <xen/bootfdt.h>
> +#include <xen/bootinfo.h>
>  #include <xen/compile.h>
>  #include <xen/device_tree.h>
>  #include <xen/init.h>
> diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
> index 529c91e603..fb4ac06390 100644
> --- a/xen/common/device-tree/bootfdt.c
> +++ b/xen/common/device-tree/bootfdt.c
> @@ -6,6 +6,7 @@
>   */
>  
>  #include <xen/bootfdt.h>

Is this kept on purpose?


> +#include <xen/bootinfo.h>
>  #include <xen/device_tree.h>
>  #include <xen/efi.h>
>  #include <xen/init.h>

Re: [PATCH 13/19] xen/dt: Move bootinfo functions to a new bootinfo.h

[Alejandro Vallejo]

On Sat May 31, 2025 at 3:42 AM CEST, Stefano Stabellini wrote:
> On Fri, 30 May 2025, Alejandro Vallejo wrote:
>> Part of an unpicking process to extract bootfdt contents independent of
>> bootinfo to a separate file for x86 to take.
>> 
>> With this, bootfdt.h can be cleanly included from x86. A later patch
>> extracts the definitions so the functions may be called too.
>> 
>> Not a functional change.
>> 
>> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
>> ---
>>  xen/arch/arm/domain_build.c             |   1 +
>>  xen/arch/arm/mmu/mm.c                   |   1 +
>>  xen/arch/riscv/mm.c                     |   2 +-
>>  xen/arch/riscv/setup.c                  |   2 +-
>>  xen/common/device-tree/bootfdt.c        |   1 +
>>  xen/common/device-tree/bootinfo.c       |   2 +-
>>  xen/common/device-tree/dom0less-build.c |   2 +-
>>  xen/common/device-tree/domain-build.c   |   2 +-
>>  xen/common/device-tree/kernel.c         |   2 +-
>>  xen/include/xen/bootfdt.h               | 206 -----------------------
>>  xen/include/xen/bootinfo.h              | 212 ++++++++++++++++++++++++
>>  xen/include/xen/device_tree.h           |   2 +-
>>  xen/include/xen/fdt-domain-build.h      |   2 +-
>>  xen/include/xen/fdt-kernel.h            |   2 +-
>>  14 files changed, 224 insertions(+), 215 deletions(-)
>>  create mode 100644 xen/include/xen/bootinfo.h
>> 
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 11cc03e5db..c53da76682 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -1,5 +1,6 @@
>>  /* SPDX-License-Identifier: GPL-2.0-only */
>>  #include <xen/init.h>
>> +#include <xen/bootinfo.h>
>>  #include <xen/compile.h>
>>  #include <xen/fdt-domain-build.h>
>>  #include <xen/fdt-kernel.h>
>> diff --git a/xen/arch/arm/mmu/mm.c b/xen/arch/arm/mmu/mm.c
>> index 9c50479c63..77f82757bb 100644
>> --- a/xen/arch/arm/mmu/mm.c
>> +++ b/xen/arch/arm/mmu/mm.c
>> @@ -1,5 +1,6 @@
>>  /* SPDX-License-Identifier: GPL-2.0-or-later */
>>  
>> +#include <xen/bootinfo.h>
>>  #include <xen/init.h>
>>  #include <xen/lib.h>
>>  #include <xen/macros.h>
>> diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
>> index d3ece9f132..040db73d00 100644
>> --- a/xen/arch/riscv/mm.c
>> +++ b/xen/arch/riscv/mm.c
>> @@ -1,6 +1,6 @@
>>  /* SPDX-License-Identifier: GPL-2.0-only */
>>  
>> -#include <xen/bootfdt.h>
>> +#include <xen/bootinfo.h>
>>  #include <xen/bug.h>
>>  #include <xen/compiler.h>
>>  #include <xen/init.h>
>> diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
>> index 4e416f6e44..0a2d0dc1eb 100644
>> --- a/xen/arch/riscv/setup.c
>> +++ b/xen/arch/riscv/setup.c
>> @@ -2,7 +2,7 @@
>>  
>>  #include <xen/acpi.h>
>>  #include <xen/bug.h>
>> -#include <xen/bootfdt.h>
>> +#include <xen/bootinfo.h>
>>  #include <xen/compile.h>
>>  #include <xen/device_tree.h>
>>  #include <xen/init.h>
>> diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
>> index 529c91e603..fb4ac06390 100644
>> --- a/xen/common/device-tree/bootfdt.c
>> +++ b/xen/common/device-tree/bootfdt.c
>> @@ -6,6 +6,7 @@
>>   */
>>  
>>  #include <xen/bootfdt.h>
>
> Is this kept on purpose?

No. Should've been subsumed

Cheers,
Alejandro

[PATCH 14/19] xen/dt: Rename bootfdt.c -> bootinfo-fdt.c

[Alejandro Vallejo]

This file will eventually contain bootfdt helpers that make heavy use of
bootinfo. To simplify git history do the rename here explicitly. A later
patch extracts bootinfo-independent helpers into bootfdt.c.

Doing so here would needlessly pollute the diffs.

Not a functional change.

Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
 xen/common/device-tree/Makefile                      | 2 +-
 xen/common/device-tree/{bootfdt.c => bootinfo-fdt.c} | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename xen/common/device-tree/{bootfdt.c => bootinfo-fdt.c} (99%)

diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index 57b9e6ca00..bb6d5ddec5 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1,4 +1,4 @@
-obj-y += bootfdt.init.o
+obj-y += bootinfo-fdt.init.o
 obj-y += bootinfo.init.o
 obj-y += device-tree.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootinfo-fdt.c
similarity index 99%
rename from xen/common/device-tree/bootfdt.c
rename to xen/common/device-tree/bootinfo-fdt.c
index fb4ac06390..bb5f45771e 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootinfo-fdt.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 /*
- * Early Device Tree
+ * Early Device Tree with bootinfo hooks
  *
  * Copyright (C) 2012-2014 Citrix Systems, Inc.
  */
-- 
2.43.0

Re: [PATCH 14/19] xen/dt: Rename bootfdt.c -> bootinfo-fdt.c

[Stefano Stabellini]

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> This file will eventually contain bootfdt helpers that make heavy use of
> bootinfo. To simplify git history do the rename here explicitly. A later
> patch extracts bootinfo-independent helpers into bootfdt.c.
> 
> Doing so here would needlessly pollute the diffs.
> 
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  xen/common/device-tree/Makefile                      | 2 +-
>  xen/common/device-tree/{bootfdt.c => bootinfo-fdt.c} | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>  rename xen/common/device-tree/{bootfdt.c => bootinfo-fdt.c} (99%)
> 
> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
> index 57b9e6ca00..bb6d5ddec5 100644
> --- a/xen/common/device-tree/Makefile
> +++ b/xen/common/device-tree/Makefile
> @@ -1,4 +1,4 @@
> -obj-y += bootfdt.init.o
> +obj-y += bootinfo-fdt.init.o
>  obj-y += bootinfo.init.o
>  obj-y += device-tree.o
>  obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o
> diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootinfo-fdt.c
> similarity index 99%
> rename from xen/common/device-tree/bootfdt.c
> rename to xen/common/device-tree/bootinfo-fdt.c
> index fb4ac06390..bb5f45771e 100644
> --- a/xen/common/device-tree/bootfdt.c
> +++ b/xen/common/device-tree/bootinfo-fdt.c
> @@ -1,6 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
>  /*
> - * Early Device Tree
> + * Early Device Tree with bootinfo hooks
>   *
>   * Copyright (C) 2012-2014 Citrix Systems, Inc.
>   */
> -- 
> 2.43.0
> 

[PATCH 15/19] xen/dt: Move bootinfo-independent helpers out of bootinfo-fdt.c

[Alejandro Vallejo]

... back into bootfdt.c

These will be required by x86 later on to detect modules in the early scan of
the FDT. They are independent of bootinfo, so it's cleaner for them to exist in
a separate file.

Not a functional change.

Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
 xen/common/device-tree/Makefile       |   1 +
 xen/common/device-tree/bootfdt.c      |  97 ++++++++++++++++++++++++
 xen/common/device-tree/bootinfo-fdt.c | 104 --------------------------
 3 files changed, 98 insertions(+), 104 deletions(-)
 create mode 100644 xen/common/device-tree/bootfdt.c

diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index bb6d5ddec5..922c5bba9b 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1,3 +1,4 @@
+obj-y += bootfdt.init.o
 obj-y += bootinfo-fdt.init.o
 obj-y += bootinfo.init.o
 obj-y += device-tree.o
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
new file mode 100644
index 0000000000..5decf17faf
--- /dev/null
+++ b/xen/common/device-tree/bootfdt.c
@@ -0,0 +1,97 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#include <xen/bootfdt.h>
+#include <xen/bug.h>
+#include <xen/lib.h>
+#include <xen/libfdt/libfdt.h>
+
+uint32_t __init device_tree_get_u32(const void *fdt, int node,
+                                    const char *prop_name, uint32_t dflt)
+{
+    const struct fdt_property *prop;
+
+    prop = fdt_get_property(fdt, node, prop_name, NULL);
+    if ( !prop || prop->len < sizeof(u32) )
+        return dflt;
+
+    return fdt32_to_cpu(*(uint32_t*)prop->data);
+}
+
+int __init device_tree_for_each_node(const void *fdt, int node,
+                                     device_tree_node_func func,
+                                     void *data)
+{
+    /*
+     * We only care about relative depth increments, assume depth of
+     * node is 0 for simplicity.
+     */
+    int depth = 0;
+    const int first_node = node;
+    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
+    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
+    int ret;
+
+    do {
+        const char *name = fdt_get_name(fdt, node, NULL);
+        u32 as, ss;
+
+        if ( depth >= DEVICE_TREE_MAX_DEPTH )
+        {
+            printk("Warning: device tree node `%s' is nested too deep\n",
+                   name);
+            continue;
+        }
+
+        as = depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_CELLS_DEFAULT;
+        ss = depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELLS_DEFAULT;
+
+        address_cells[depth] = device_tree_get_u32(fdt, node,
+                                                   "#address-cells", as);
+        size_cells[depth] = device_tree_get_u32(fdt, node,
+                                                "#size-cells", ss);
+
+        /* skip the first node */
+        if ( node != first_node )
+        {
+            ret = func(fdt, node, name, depth, as, ss, data);
+            if ( ret != 0 )
+                return ret;
+        }
+
+        node = fdt_next_node(fdt, node, &depth);
+    } while ( node >= 0 && depth > 0 );
+
+    return 0;
+}
+
+void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
+                                uint32_t size_cells, paddr_t *start,
+                                paddr_t *size)
+{
+    uint64_t dt_start, dt_size;
+
+    /*
+     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit.
+     * Thus, there is an implicit cast from uint64_t to paddr_t.
+     */
+    dt_start = dt_next_cell(address_cells, cell);
+    dt_size = dt_next_cell(size_cells, cell);
+
+    if ( dt_start != (paddr_t)dt_start )
+    {
+        printk("Physical address greater than max width supported\n");
+        WARN();
+    }
+
+    if ( dt_size != (paddr_t)dt_size )
+    {
+        printk("Physical size greater than max width supported\n");
+        WARN();
+    }
+
+    /*
+     * Xen will truncate the address/size if it is greater than the maximum
+     * supported width and it will give an appropriate warning.
+     */
+    *start = dt_start;
+    *size = dt_size;
+}
diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tree/bootinfo-fdt.c
index bb5f45771e..736f877616 100644
--- a/xen/common/device-tree/bootinfo-fdt.c
+++ b/xen/common/device-tree/bootinfo-fdt.c
@@ -112,39 +112,6 @@ static bool __init device_tree_is_memory_node(const void *fdt, int node,
     return true;
 }
 
-void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
-                                uint32_t size_cells, paddr_t *start,
-                                paddr_t *size)
-{
-    uint64_t dt_start, dt_size;
-
-    /*
-     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit.
-     * Thus, there is an implicit cast from uint64_t to paddr_t.
-     */
-    dt_start = dt_next_cell(address_cells, cell);
-    dt_size = dt_next_cell(size_cells, cell);
-
-    if ( dt_start != (paddr_t)dt_start )
-    {
-        printk("Physical address greater than max width supported\n");
-        WARN();
-    }
-
-    if ( dt_size != (paddr_t)dt_size )
-    {
-        printk("Physical size greater than max width supported\n");
-        WARN();
-    }
-
-    /*
-     * Xen will truncate the address/size if it is greater than the maximum
-     * supported width and it will give an appropriate warning.
-     */
-    *start = dt_start;
-    *size = dt_size;
-}
-
 static int __init device_tree_get_meminfo(const void *fdt, int node,
                                           const char *prop_name,
                                           u32 address_cells, u32 size_cells,
@@ -205,77 +172,6 @@ static int __init device_tree_get_meminfo(const void *fdt, int node,
     return 0;
 }
 
-u32 __init device_tree_get_u32(const void *fdt, int node,
-                               const char *prop_name, u32 dflt)
-{
-    const struct fdt_property *prop;
-
-    prop = fdt_get_property(fdt, node, prop_name, NULL);
-    if ( !prop || prop->len < sizeof(u32) )
-        return dflt;
-
-    return fdt32_to_cpu(*(uint32_t*)prop->data);
-}
-
-/**
- * device_tree_for_each_node - iterate over all device tree sub-nodes
- * @fdt: flat device tree.
- * @node: parent node to start the search from
- * @func: function to call for each sub-node.
- * @data: data to pass to @func.
- *
- * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
- *
- * Returns 0 if all nodes were iterated over successfully.  If @func
- * returns a value different from 0, that value is returned immediately.
- */
-int __init device_tree_for_each_node(const void *fdt, int node,
-                                     device_tree_node_func func,
-                                     void *data)
-{
-    /*
-     * We only care about relative depth increments, assume depth of
-     * node is 0 for simplicity.
-     */
-    int depth = 0;
-    const int first_node = node;
-    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
-    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
-    int ret;
-
-    do {
-        const char *name = fdt_get_name(fdt, node, NULL);
-        u32 as, ss;
-
-        if ( depth >= DEVICE_TREE_MAX_DEPTH )
-        {
-            printk("Warning: device tree node `%s' is nested too deep\n",
-                   name);
-            continue;
-        }
-
-        as = depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_CELLS_DEFAULT;
-        ss = depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELLS_DEFAULT;
-
-        address_cells[depth] = device_tree_get_u32(fdt, node,
-                                                   "#address-cells", as);
-        size_cells[depth] = device_tree_get_u32(fdt, node,
-                                                "#size-cells", ss);
-
-        /* skip the first node */
-        if ( node != first_node )
-        {
-            ret = func(fdt, node, name, depth, as, ss, data);
-            if ( ret != 0 )
-                return ret;
-        }
-
-        node = fdt_next_node(fdt, node, &depth);
-    } while ( node >= 0 && depth > 0 );
-
-    return 0;
-}
-
 static int __init process_memory_node(const void *fdt, int node,
                                       const char *name, int depth,
                                       u32 address_cells, u32 size_cells,
-- 
2.43.0

Re: [PATCH 15/19] xen/dt: Move bootinfo-independent helpers out of bootinfo-fdt.c

[dmkhn]

On Fri, May 30, 2025 at 02:02:23PM +0200, Alejandro Vallejo wrote:
> ... back into bootfdt.c
> 
> These will be required by x86 later on to detect modules in the early scan of
> the FDT. They are independent of bootinfo, so it's cleaner for them to exist in
> a separate file.
> 
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
> ---
>  xen/common/device-tree/Makefile       |   1 +
>  xen/common/device-tree/bootfdt.c      |  97 ++++++++++++++++++++++++
>  xen/common/device-tree/bootinfo-fdt.c | 104 --------------------------
>  3 files changed, 98 insertions(+), 104 deletions(-)
>  create mode 100644 xen/common/device-tree/bootfdt.c
> 
> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
> index bb6d5ddec5..922c5bba9b 100644
> --- a/xen/common/device-tree/Makefile
> +++ b/xen/common/device-tree/Makefile
> @@ -1,3 +1,4 @@
> +obj-y += bootfdt.init.o
>  obj-y += bootinfo-fdt.init.o
>  obj-y += bootinfo.init.o
>  obj-y += device-tree.o
> diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
> new file mode 100644
> index 0000000000..5decf17faf
> --- /dev/null
> +++ b/xen/common/device-tree/bootfdt.c
> @@ -0,0 +1,97 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#include <xen/bootfdt.h>
> +#include <xen/bug.h>
> +#include <xen/lib.h>
> +#include <xen/libfdt/libfdt.h>
> +
> +uint32_t __init device_tree_get_u32(const void *fdt, int node,
> +                                    const char *prop_name, uint32_t dflt)
> +{
> +    const struct fdt_property *prop;
> +
> +    prop = fdt_get_property(fdt, node, prop_name, NULL);
> +    if ( !prop || prop->len < sizeof(u32) )
> +        return dflt;
> +
> +    return fdt32_to_cpu(*(uint32_t*)prop->data);
> +}
> +
> +int __init device_tree_for_each_node(const void *fdt, int node,
> +                                     device_tree_node_func func,
> +                                     void *data)
> +{
> +    /*
> +     * We only care about relative depth increments, assume depth of
> +     * node is 0 for simplicity.
> +     */
> +    int depth = 0;
> +    const int first_node = node;
> +    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
> +    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
> +    int ret;
> +
> +    do {
> +        const char *name = fdt_get_name(fdt, node, NULL);
> +        u32 as, ss;
> +
> +        if ( depth >= DEVICE_TREE_MAX_DEPTH )
> +        {
> +            printk("Warning: device tree node `%s' is nested too deep\n",
> +                   name);

Use XENLOG_WARNING?

> +            continue;
> +        }
> +
> +        as = depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_CELLS_DEFAULT;
> +        ss = depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELLS_DEFAULT;
> +
> +        address_cells[depth] = device_tree_get_u32(fdt, node,
> +                                                   "#address-cells", as);
> +        size_cells[depth] = device_tree_get_u32(fdt, node,
> +                                                "#size-cells", ss);
> +
> +        /* skip the first node */
> +        if ( node != first_node )
> +        {
> +            ret = func(fdt, node, name, depth, as, ss, data);
> +            if ( ret != 0 )
> +                return ret;
> +        }
> +
> +        node = fdt_next_node(fdt, node, &depth);
> +    } while ( node >= 0 && depth > 0 );
> +
> +    return 0;
> +}
> +
> +void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> +                                uint32_t size_cells, paddr_t *start,
> +                                paddr_t *size)
> +{
> +    uint64_t dt_start, dt_size;
> +
> +    /*
> +     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit.
> +     * Thus, there is an implicit cast from uint64_t to paddr_t.
> +     */
> +    dt_start = dt_next_cell(address_cells, cell);
> +    dt_size = dt_next_cell(size_cells, cell);
> +
> +    if ( dt_start != (paddr_t)dt_start )
> +    {
> +        printk("Physical address greater than max width supported\n");

I would add current and expected dt_start values to the printout.

> +        WARN();
> +    }
> +
> +    if ( dt_size != (paddr_t)dt_size )
> +    {
> +        printk("Physical size greater than max width supported\n");
> +        WARN();
> +    }
> +
> +    /*
> +     * Xen will truncate the address/size if it is greater than the maximum
> +     * supported width and it will give an appropriate warning.
> +     */
> +    *start = dt_start;
> +    *size = dt_size;
> +}
> diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tree/bootinfo-fdt.c
> index bb5f45771e..736f877616 100644
> --- a/xen/common/device-tree/bootinfo-fdt.c
> +++ b/xen/common/device-tree/bootinfo-fdt.c
> @@ -112,39 +112,6 @@ static bool __init device_tree_is_memory_node(const void *fdt, int node,
>      return true;
>  }
> 
> -void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> -                                uint32_t size_cells, paddr_t *start,
> -                                paddr_t *size)
> -{
> -    uint64_t dt_start, dt_size;
> -
> -    /*
> -     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit.
> -     * Thus, there is an implicit cast from uint64_t to paddr_t.
> -     */
> -    dt_start = dt_next_cell(address_cells, cell);
> -    dt_size = dt_next_cell(size_cells, cell);
> -
> -    if ( dt_start != (paddr_t)dt_start )
> -    {
> -        printk("Physical address greater than max width supported\n");
> -        WARN();
> -    }
> -
> -    if ( dt_size != (paddr_t)dt_size )
> -    {
> -        printk("Physical size greater than max width supported\n");
> -        WARN();
> -    }
> -
> -    /*
> -     * Xen will truncate the address/size if it is greater than the maximum
> -     * supported width and it will give an appropriate warning.
> -     */
> -    *start = dt_start;
> -    *size = dt_size;
> -}
> -
>  static int __init device_tree_get_meminfo(const void *fdt, int node,
>                                            const char *prop_name,
>                                            u32 address_cells, u32 size_cells,
> @@ -205,77 +172,6 @@ static int __init device_tree_get_meminfo(const void *fdt, int node,
>      return 0;
>  }
> 
> -u32 __init device_tree_get_u32(const void *fdt, int node,
> -                               const char *prop_name, u32 dflt)
> -{
> -    const struct fdt_property *prop;
> -
> -    prop = fdt_get_property(fdt, node, prop_name, NULL);
> -    if ( !prop || prop->len < sizeof(u32) )
> -        return dflt;
> -
> -    return fdt32_to_cpu(*(uint32_t*)prop->data);
> -}
> -
> -/**
> - * device_tree_for_each_node - iterate over all device tree sub-nodes
> - * @fdt: flat device tree.
> - * @node: parent node to start the search from
> - * @func: function to call for each sub-node.
> - * @data: data to pass to @func.
> - *
> - * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
> - *
> - * Returns 0 if all nodes were iterated over successfully.  If @func
> - * returns a value different from 0, that value is returned immediately.
> - */
> -int __init device_tree_for_each_node(const void *fdt, int node,
> -                                     device_tree_node_func func,
> -                                     void *data)
> -{
> -    /*
> -     * We only care about relative depth increments, assume depth of
> -     * node is 0 for simplicity.
> -     */
> -    int depth = 0;
> -    const int first_node = node;
> -    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
> -    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
> -    int ret;
> -
> -    do {
> -        const char *name = fdt_get_name(fdt, node, NULL);
> -        u32 as, ss;
> -
> -        if ( depth >= DEVICE_TREE_MAX_DEPTH )
> -        {
> -            printk("Warning: device tree node `%s' is nested too deep\n",
> -                   name);
> -            continue;
> -        }
> -
> -        as = depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_CELLS_DEFAULT;
> -        ss = depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELLS_DEFAULT;
> -
> -        address_cells[depth] = device_tree_get_u32(fdt, node,
> -                                                   "#address-cells", as);
> -        size_cells[depth] = device_tree_get_u32(fdt, node,
> -                                                "#size-cells", ss);
> -
> -        /* skip the first node */
> -        if ( node != first_node )
> -        {
> -            ret = func(fdt, node, name, depth, as, ss, data);
> -            if ( ret != 0 )
> -                return ret;
> -        }
> -
> -        node = fdt_next_node(fdt, node, &depth);
> -    } while ( node >= 0 && depth > 0 );
> -
> -    return 0;
> -}
> -
>  static int __init process_memory_node(const void *fdt, int node,
>                                        const char *name, int depth,
>                                        u32 address_cells, u32 size_cells,
> --
> 2.43.0
> 
> 

Re: [PATCH 15/19] xen/dt: Move bootinfo-independent helpers out of bootinfo-fdt.c

[Alejandro Vallejo]

On Sat May 31, 2025 at 2:39 AM CEST, dmkhn wrote:
> On Fri, May 30, 2025 at 02:02:23PM +0200, Alejandro Vallejo wrote:
>> ... back into bootfdt.c
>> 
>> These will be required by x86 later on to detect modules in the early scan of
>> the FDT. They are independent of bootinfo, so it's cleaner for them to exist in
>> a separate file.
>> 
>> Not a functional change.
>> 
>> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
>> ---
>>  xen/common/device-tree/Makefile       |   1 +
>>  xen/common/device-tree/bootfdt.c      |  97 ++++++++++++++++++++++++
>>  xen/common/device-tree/bootinfo-fdt.c | 104 --------------------------
>>  3 files changed, 98 insertions(+), 104 deletions(-)
>>  create mode 100644 xen/common/device-tree/bootfdt.c
>> 
>> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
>> index bb6d5ddec5..922c5bba9b 100644
>> --- a/xen/common/device-tree/Makefile
>> +++ b/xen/common/device-tree/Makefile
>> @@ -1,3 +1,4 @@
>> +obj-y += bootfdt.init.o
>>  obj-y += bootinfo-fdt.init.o
>>  obj-y += bootinfo.init.o
>>  obj-y += device-tree.o
>> diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
>> new file mode 100644
>> index 0000000000..5decf17faf
>> --- /dev/null
>> +++ b/xen/common/device-tree/bootfdt.c
>> @@ -0,0 +1,97 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +#include <xen/bootfdt.h>
>> +#include <xen/bug.h>
>> +#include <xen/lib.h>
>> +#include <xen/libfdt/libfdt.h>
>> +
>> +uint32_t __init device_tree_get_u32(const void *fdt, int node,
>> +                                    const char *prop_name, uint32_t dflt)
>> +{
>> +    const struct fdt_property *prop;
>> +
>> +    prop = fdt_get_property(fdt, node, prop_name, NULL);
>> +    if ( !prop || prop->len < sizeof(u32) )
>> +        return dflt;
>> +
>> +    return fdt32_to_cpu(*(uint32_t*)prop->data);
>> +}
>> +
>> +int __init device_tree_for_each_node(const void *fdt, int node,
>> +                                     device_tree_node_func func,
>> +                                     void *data)
>> +{
>> +    /*
>> +     * We only care about relative depth increments, assume depth of
>> +     * node is 0 for simplicity.
>> +     */
>> +    int depth = 0;
>> +    const int first_node = node;
>> +    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
>> +    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
>> +    int ret;
>> +
>> +    do {
>> +        const char *name = fdt_get_name(fdt, node, NULL);
>> +        u32 as, ss;
>> +
>> +        if ( depth >= DEVICE_TREE_MAX_DEPTH )
>> +        {
>> +            printk("Warning: device tree node `%s' is nested too deep\n",
>> +                   name);
>
> Use XENLOG_WARNING?
>
>> +            continue;
>> +        }
>> +
>> +        as = depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_CELLS_DEFAULT;
>> +        ss = depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELLS_DEFAULT;
>> +
>> +        address_cells[depth] = device_tree_get_u32(fdt, node,
>> +                                                   "#address-cells", as);
>> +        size_cells[depth] = device_tree_get_u32(fdt, node,
>> +                                                "#size-cells", ss);
>> +
>> +        /* skip the first node */
>> +        if ( node != first_node )
>> +        {
>> +            ret = func(fdt, node, name, depth, as, ss, data);
>> +            if ( ret != 0 )
>> +                return ret;
>> +        }
>> +
>> +        node = fdt_next_node(fdt, node, &depth);
>> +    } while ( node >= 0 && depth > 0 );
>> +
>> +    return 0;
>> +}
>> +
>> +void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
>> +                                uint32_t size_cells, paddr_t *start,
>> +                                paddr_t *size)
>> +{
>> +    uint64_t dt_start, dt_size;
>> +
>> +    /*
>> +     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit.
>> +     * Thus, there is an implicit cast from uint64_t to paddr_t.
>> +     */
>> +    dt_start = dt_next_cell(address_cells, cell);
>> +    dt_size = dt_next_cell(size_cells, cell);
>> +
>> +    if ( dt_start != (paddr_t)dt_start )
>> +    {
>> +        printk("Physical address greater than max width supported\n");
>
> I would add current and expected dt_start values to the printout.
>
>> +        WARN();
>> +    }
>> +
>> +    if ( dt_size != (paddr_t)dt_size )
>> +    {
>> +        printk("Physical size greater than max width supported\n");
>> +        WARN();
>> +    }
>> +
>> +    /*
>> +     * Xen will truncate the address/size if it is greater than the maximum
>> +     * supported width and it will give an appropriate warning.
>> +     */
>> +    *start = dt_start;
>> +    *size = dt_size;
>> +}
>> diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tree/bootinfo-fdt.c
>> index bb5f45771e..736f877616 100644
>> --- a/xen/common/device-tree/bootinfo-fdt.c
>> +++ b/xen/common/device-tree/bootinfo-fdt.c
>> @@ -112,39 +112,6 @@ static bool __init device_tree_is_memory_node(const void *fdt, int node,
>>      return true;
>>  }
>> 
>> -void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
>> -                                uint32_t size_cells, paddr_t *start,
>> -                                paddr_t *size)
>> -{
>> -    uint64_t dt_start, dt_size;
>> -
>> -    /*
>> -     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit.
>> -     * Thus, there is an implicit cast from uint64_t to paddr_t.
>> -     */
>> -    dt_start = dt_next_cell(address_cells, cell);
>> -    dt_size = dt_next_cell(size_cells, cell);
>> -
>> -    if ( dt_start != (paddr_t)dt_start )
>> -    {
>> -        printk("Physical address greater than max width supported\n");
>> -        WARN();
>> -    }
>> -
>> -    if ( dt_size != (paddr_t)dt_size )
>> -    {
>> -        printk("Physical size greater than max width supported\n");
>> -        WARN();
>> -    }
>> -
>> -    /*
>> -     * Xen will truncate the address/size if it is greater than the maximum
>> -     * supported width and it will give an appropriate warning.
>> -     */
>> -    *start = dt_start;
>> -    *size = dt_size;
>> -}
>> -
>>  static int __init device_tree_get_meminfo(const void *fdt, int node,
>>                                            const char *prop_name,
>>                                            u32 address_cells, u32 size_cells,
>> @@ -205,77 +172,6 @@ static int __init device_tree_get_meminfo(const void *fdt, int node,
>>      return 0;
>>  }
>> 
>> -u32 __init device_tree_get_u32(const void *fdt, int node,
>> -                               const char *prop_name, u32 dflt)
>> -{
>> -    const struct fdt_property *prop;
>> -
>> -    prop = fdt_get_property(fdt, node, prop_name, NULL);
>> -    if ( !prop || prop->len < sizeof(u32) )
>> -        return dflt;
>> -
>> -    return fdt32_to_cpu(*(uint32_t*)prop->data);
>> -}
>> -
>> -/**
>> - * device_tree_for_each_node - iterate over all device tree sub-nodes
>> - * @fdt: flat device tree.
>> - * @node: parent node to start the search from
>> - * @func: function to call for each sub-node.
>> - * @data: data to pass to @func.
>> - *
>> - * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
>> - *
>> - * Returns 0 if all nodes were iterated over successfully.  If @func
>> - * returns a value different from 0, that value is returned immediately.
>> - */
>> -int __init device_tree_for_each_node(const void *fdt, int node,
>> -                                     device_tree_node_func func,
>> -                                     void *data)
>> -{
>> -    /*
>> -     * We only care about relative depth increments, assume depth of
>> -     * node is 0 for simplicity.
>> -     */
>> -    int depth = 0;
>> -    const int first_node = node;
>> -    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
>> -    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
>> -    int ret;
>> -
>> -    do {
>> -        const char *name = fdt_get_name(fdt, node, NULL);
>> -        u32 as, ss;
>> -
>> -        if ( depth >= DEVICE_TREE_MAX_DEPTH )
>> -        {
>> -            printk("Warning: device tree node `%s' is nested too deep\n",
>> -                   name);
>> -            continue;
>> -        }
>> -
>> -        as = depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_CELLS_DEFAULT;
>> -        ss = depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELLS_DEFAULT;
>> -
>> -        address_cells[depth] = device_tree_get_u32(fdt, node,
>> -                                                   "#address-cells", as);
>> -        size_cells[depth] = device_tree_get_u32(fdt, node,
>> -                                                "#size-cells", ss);
>> -
>> -        /* skip the first node */
>> -        if ( node != first_node )
>> -        {
>> -            ret = func(fdt, node, name, depth, as, ss, data);
>> -            if ( ret != 0 )
>> -                return ret;
>> -        }
>> -
>> -        node = fdt_next_node(fdt, node, &depth);
>> -    } while ( node >= 0 && depth > 0 );
>> -
>> -    return 0;
>> -}
>> -
>>  static int __init process_memory_node(const void *fdt, int node,
>>                                        const char *name, int depth,
>>                                        u32 address_cells, u32 size_cells,
>> --
>> 2.43.0
>> 
>> 

As I answered to Daniel, as I'd rather not introduce functional changes in
code motion commits. I draw the line at trivial retyping (e.g: u32->uint32_t)

Otherwise it's just very confusing to future readers.

Cheers,
Alejandro

Re: [PATCH 15/19] xen/dt: Move bootinfo-independent helpers out of bootinfo-fdt.c

[Stefano Stabellini]

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> ... back into bootfdt.c
> 
> These will be required by x86 later on to detect modules in the early scan of
> the FDT. They are independent of bootinfo, so it's cleaner for them to exist in
> a separate file.
> 
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
> ---
>  xen/common/device-tree/Makefile       |   1 +
>  xen/common/device-tree/bootfdt.c      |  97 ++++++++++++++++++++++++
>  xen/common/device-tree/bootinfo-fdt.c | 104 --------------------------
>  3 files changed, 98 insertions(+), 104 deletions(-)
>  create mode 100644 xen/common/device-tree/bootfdt.c
> 
> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
> index bb6d5ddec5..922c5bba9b 100644
> --- a/xen/common/device-tree/Makefile
> +++ b/xen/common/device-tree/Makefile
> @@ -1,3 +1,4 @@
> +obj-y += bootfdt.init.o
>  obj-y += bootinfo-fdt.init.o
>  obj-y += bootinfo.init.o
>  obj-y += device-tree.o
> diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
> new file mode 100644
> index 0000000000..5decf17faf
> --- /dev/null
> +++ b/xen/common/device-tree/bootfdt.c
> @@ -0,0 +1,97 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#include <xen/bootfdt.h>
> +#include <xen/bug.h>
> +#include <xen/lib.h>
> +#include <xen/libfdt/libfdt.h>
> +
> +uint32_t __init device_tree_get_u32(const void *fdt, int node,
> +                                    const char *prop_name, uint32_t dflt)
> +{
> +    const struct fdt_property *prop;
> +
> +    prop = fdt_get_property(fdt, node, prop_name, NULL);
> +    if ( !prop || prop->len < sizeof(u32) )

Ah this is where the u32->uint32_t renaming is done!
Since we are at it, we can change the u32 in the sizeof


> +        return dflt;
> +
> +    return fdt32_to_cpu(*(uint32_t*)prop->data);
> +}
> +
> +int __init device_tree_for_each_node(const void *fdt, int node,
> +                                     device_tree_node_func func,
> +                                     void *data)
> +{
> +    /*
> +     * We only care about relative depth increments, assume depth of
> +     * node is 0 for simplicity.
> +     */
> +    int depth = 0;
> +    const int first_node = node;
> +    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
> +    u32 size_cells[DEVICE_TREE_MAX_DEPTH];

same here?


> +    int ret;
> +
> +    do {
> +        const char *name = fdt_get_name(fdt, node, NULL);
> +        u32 as, ss;
> +
> +        if ( depth >= DEVICE_TREE_MAX_DEPTH )
> +        {
> +            printk("Warning: device tree node `%s' is nested too deep\n",
> +                   name);
> +            continue;
> +        }
> +
> +        as = depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_CELLS_DEFAULT;
> +        ss = depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELLS_DEFAULT;
> +
> +        address_cells[depth] = device_tree_get_u32(fdt, node,
> +                                                   "#address-cells", as);
> +        size_cells[depth] = device_tree_get_u32(fdt, node,
> +                                                "#size-cells", ss);
> +
> +        /* skip the first node */
> +        if ( node != first_node )
> +        {
> +            ret = func(fdt, node, name, depth, as, ss, data);
> +            if ( ret != 0 )
> +                return ret;
> +        }
> +
> +        node = fdt_next_node(fdt, node, &depth);
> +    } while ( node >= 0 && depth > 0 );
> +
> +    return 0;
> +}
> +
> +void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> +                                uint32_t size_cells, paddr_t *start,
> +                                paddr_t *size)
> +{
> +    uint64_t dt_start, dt_size;
> +
> +    /*
> +     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit.
> +     * Thus, there is an implicit cast from uint64_t to paddr_t.
> +     */
> +    dt_start = dt_next_cell(address_cells, cell);
> +    dt_size = dt_next_cell(size_cells, cell);
> +
> +    if ( dt_start != (paddr_t)dt_start )
> +    {
> +        printk("Physical address greater than max width supported\n");
> +        WARN();
> +    }
> +
> +    if ( dt_size != (paddr_t)dt_size )
> +    {
> +        printk("Physical size greater than max width supported\n");
> +        WARN();
> +    }
> +
> +    /*
> +     * Xen will truncate the address/size if it is greater than the maximum
> +     * supported width and it will give an appropriate warning.
> +     */
> +    *start = dt_start;
> +    *size = dt_size;
> +}
> diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tree/bootinfo-fdt.c
> index bb5f45771e..736f877616 100644
> --- a/xen/common/device-tree/bootinfo-fdt.c
> +++ b/xen/common/device-tree/bootinfo-fdt.c
> @@ -112,39 +112,6 @@ static bool __init device_tree_is_memory_node(const void *fdt, int node,
>      return true;
>  }
>  
> -void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> -                                uint32_t size_cells, paddr_t *start,
> -                                paddr_t *size)
> -{
> -    uint64_t dt_start, dt_size;
> -
> -    /*
> -     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit.
> -     * Thus, there is an implicit cast from uint64_t to paddr_t.
> -     */
> -    dt_start = dt_next_cell(address_cells, cell);
> -    dt_size = dt_next_cell(size_cells, cell);
> -
> -    if ( dt_start != (paddr_t)dt_start )
> -    {
> -        printk("Physical address greater than max width supported\n");
> -        WARN();
> -    }
> -
> -    if ( dt_size != (paddr_t)dt_size )
> -    {
> -        printk("Physical size greater than max width supported\n");
> -        WARN();
> -    }
> -
> -    /*
> -     * Xen will truncate the address/size if it is greater than the maximum
> -     * supported width and it will give an appropriate warning.
> -     */
> -    *start = dt_start;
> -    *size = dt_size;
> -}
> -
>  static int __init device_tree_get_meminfo(const void *fdt, int node,
>                                            const char *prop_name,
>                                            u32 address_cells, u32 size_cells,
> @@ -205,77 +172,6 @@ static int __init device_tree_get_meminfo(const void *fdt, int node,
>      return 0;
>  }
>  
> -u32 __init device_tree_get_u32(const void *fdt, int node,
> -                               const char *prop_name, u32 dflt)
> -{
> -    const struct fdt_property *prop;
> -
> -    prop = fdt_get_property(fdt, node, prop_name, NULL);
> -    if ( !prop || prop->len < sizeof(u32) )
> -        return dflt;
> -
> -    return fdt32_to_cpu(*(uint32_t*)prop->data);
> -}
> -
> -/**
> - * device_tree_for_each_node - iterate over all device tree sub-nodes
> - * @fdt: flat device tree.
> - * @node: parent node to start the search from
> - * @func: function to call for each sub-node.
> - * @data: data to pass to @func.
> - *
> - * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
> - *
> - * Returns 0 if all nodes were iterated over successfully.  If @func
> - * returns a value different from 0, that value is returned immediately.
> - */
> -int __init device_tree_for_each_node(const void *fdt, int node,
> -                                     device_tree_node_func func,
> -                                     void *data)
> -{
> -    /*
> -     * We only care about relative depth increments, assume depth of
> -     * node is 0 for simplicity.
> -     */
> -    int depth = 0;
> -    const int first_node = node;
> -    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
> -    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
> -    int ret;
> -
> -    do {
> -        const char *name = fdt_get_name(fdt, node, NULL);
> -        u32 as, ss;
> -
> -        if ( depth >= DEVICE_TREE_MAX_DEPTH )
> -        {
> -            printk("Warning: device tree node `%s' is nested too deep\n",
> -                   name);
> -            continue;
> -        }
> -
> -        as = depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_CELLS_DEFAULT;
> -        ss = depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELLS_DEFAULT;
> -
> -        address_cells[depth] = device_tree_get_u32(fdt, node,
> -                                                   "#address-cells", as);
> -        size_cells[depth] = device_tree_get_u32(fdt, node,
> -                                                "#size-cells", ss);
> -
> -        /* skip the first node */
> -        if ( node != first_node )
> -        {
> -            ret = func(fdt, node, name, depth, as, ss, data);
> -            if ( ret != 0 )
> -                return ret;
> -        }
> -
> -        node = fdt_next_node(fdt, node, &depth);
> -    } while ( node >= 0 && depth > 0 );
> -
> -    return 0;
> -}
> -
>  static int __init process_memory_node(const void *fdt, int node,
>                                        const char *name, int depth,
>                                        u32 address_cells, u32 size_cells,
> -- 
> 2.43.0
> 

Re: [PATCH 15/19] xen/dt: Move bootinfo-independent helpers out of bootinfo-fdt.c

[Jan Beulich]

On 31.05.2025 03:47, Stefano Stabellini wrote:
> On Fri, 30 May 2025, Alejandro Vallejo wrote:
>> --- /dev/null
>> +++ b/xen/common/device-tree/bootfdt.c
>> @@ -0,0 +1,97 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +#include <xen/bootfdt.h>
>> +#include <xen/bug.h>
>> +#include <xen/lib.h>
>> +#include <xen/libfdt/libfdt.h>
>> +
>> +uint32_t __init device_tree_get_u32(const void *fdt, int node,
>> +                                    const char *prop_name, uint32_t dflt)
>> +{
>> +    const struct fdt_property *prop;
>> +
>> +    prop = fdt_get_property(fdt, node, prop_name, NULL);
>> +    if ( !prop || prop->len < sizeof(u32) )
> 
> Ah this is where the u32->uint32_t renaming is done!
> Since we are at it, we can change the u32 in the sizeof
> 
> 
>> +        return dflt;
>> +
>> +    return fdt32_to_cpu(*(uint32_t*)prop->data);

And avoid to cast away const-ness here.

Jan

[PATCH 16/19] xen/dt: Extract helper to map nodes to module kinds

[Alejandro Vallejo]

This will be required later by x86 code in order to do early identification
of boot modules when booting off a DTB.

Not a functional change.

Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
 xen/common/device-tree/bootfdt.c      | 16 ++++++++++++++++
 xen/common/device-tree/bootinfo-fdt.c | 14 +-------------
 xen/include/xen/bootfdt.h             |  7 +++++++
 3 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index 5decf17faf..2dda7a9d19 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -4,6 +4,22 @@
 #include <xen/lib.h>
 #include <xen/libfdt/libfdt.h>
 
+bootmodule_kind __init fdt_node_to_kind(const void *fdt, int node)
+{
+    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
+         fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
+        return BOOTMOD_KERNEL;
+    if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0 ||
+         fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
+        return BOOTMOD_RAMDISK;
+    if ( fdt_node_check_compatible(fdt, node, "xen,xsm-policy") == 0 )
+        return BOOTMOD_XSM;
+    if ( fdt_node_check_compatible(fdt, node, "multiboot,device-tree") == 0 )
+        return BOOTMOD_GUEST_DTB;
+
+    return BOOTMOD_UNKNOWN;
+}
+
 uint32_t __init device_tree_get_u32(const void *fdt, int node,
                                     const char *prop_name, uint32_t dflt)
 {
diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tree/bootinfo-fdt.c
index 736f877616..dc399bbf61 100644
--- a/xen/common/device-tree/bootinfo-fdt.c
+++ b/xen/common/device-tree/bootinfo-fdt.c
@@ -239,19 +239,7 @@ static void __init process_multiboot_node(const void *fdt, int node,
 
     cell = (const __be32 *)prop->data;
     device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
-
-    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
-         fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
-        kind = BOOTMOD_KERNEL;
-    else if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0 ||
-              fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
-        kind = BOOTMOD_RAMDISK;
-    else if ( fdt_node_check_compatible(fdt, node, "xen,xsm-policy") == 0 )
-        kind = BOOTMOD_XSM;
-    else if ( fdt_node_check_compatible(fdt, node, "multiboot,device-tree") == 0 )
-        kind = BOOTMOD_GUEST_DTB;
-    else
-        kind = BOOTMOD_UNKNOWN;
+    kind = fdt_node_to_kind(fdt, node);
 
     /**
      * Guess the kind of these first two unknowns respectively:
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 766956e102..7bc6209986 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -102,4 +102,11 @@ uint32_t device_tree_get_u32(const void *fdt, int node,
 void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
                          uint32_t size_cells, paddr_t *start, paddr_t *size);
 
+/*
+ * Probe an FDT node thought to be a boot module to identify its kind.
+ *
+ * If correctly identified, returns the detected kind, otherwise BOOTMOD_UNKNOWN
+ */
+bootmodule_kind fdt_node_to_kind(const void *fdt, int node);
+
 #endif /* XEN_BOOTFDT_H */
-- 
2.43.0

Re: [PATCH 16/19] xen/dt: Extract helper to map nodes to module kinds

[Stefano Stabellini]

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> This will be required later by x86 code in order to do early identification
> of boot modules when booting off a DTB.
> 
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  xen/common/device-tree/bootfdt.c      | 16 ++++++++++++++++
>  xen/common/device-tree/bootinfo-fdt.c | 14 +-------------
>  xen/include/xen/bootfdt.h             |  7 +++++++
>  3 files changed, 24 insertions(+), 13 deletions(-)
> 
> diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
> index 5decf17faf..2dda7a9d19 100644
> --- a/xen/common/device-tree/bootfdt.c
> +++ b/xen/common/device-tree/bootfdt.c
> @@ -4,6 +4,22 @@
>  #include <xen/lib.h>
>  #include <xen/libfdt/libfdt.h>
>  
> +bootmodule_kind __init fdt_node_to_kind(const void *fdt, int node)
> +{
> +    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
> +         fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
> +        return BOOTMOD_KERNEL;
> +    if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0 ||
> +         fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
> +        return BOOTMOD_RAMDISK;
> +    if ( fdt_node_check_compatible(fdt, node, "xen,xsm-policy") == 0 )
> +        return BOOTMOD_XSM;
> +    if ( fdt_node_check_compatible(fdt, node, "multiboot,device-tree") == 0 )
> +        return BOOTMOD_GUEST_DTB;
> +
> +    return BOOTMOD_UNKNOWN;
> +}
> +
>  uint32_t __init device_tree_get_u32(const void *fdt, int node,
>                                      const char *prop_name, uint32_t dflt)
>  {
> diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tree/bootinfo-fdt.c
> index 736f877616..dc399bbf61 100644
> --- a/xen/common/device-tree/bootinfo-fdt.c
> +++ b/xen/common/device-tree/bootinfo-fdt.c
> @@ -239,19 +239,7 @@ static void __init process_multiboot_node(const void *fdt, int node,
>  
>      cell = (const __be32 *)prop->data;
>      device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
> -
> -    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
> -         fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
> -        kind = BOOTMOD_KERNEL;
> -    else if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0 ||
> -              fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
> -        kind = BOOTMOD_RAMDISK;
> -    else if ( fdt_node_check_compatible(fdt, node, "xen,xsm-policy") == 0 )
> -        kind = BOOTMOD_XSM;
> -    else if ( fdt_node_check_compatible(fdt, node, "multiboot,device-tree") == 0 )
> -        kind = BOOTMOD_GUEST_DTB;
> -    else
> -        kind = BOOTMOD_UNKNOWN;
> +    kind = fdt_node_to_kind(fdt, node);
>  
>      /**
>       * Guess the kind of these first two unknowns respectively:
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index 766956e102..7bc6209986 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -102,4 +102,11 @@ uint32_t device_tree_get_u32(const void *fdt, int node,
>  void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
>                           uint32_t size_cells, paddr_t *start, paddr_t *size);
>  
> +/*
> + * Probe an FDT node thought to be a boot module to identify its kind.
> + *
> + * If correctly identified, returns the detected kind, otherwise BOOTMOD_UNKNOWN
> + */
> +bootmodule_kind fdt_node_to_kind(const void *fdt, int node);
> +
>  #endif /* XEN_BOOTFDT_H */
> -- 
> 2.43.0
> 

[PATCH 17/19] xen/dt: ifdef out DEV_DT-related bits from device_tree.{c,h}

[Alejandro Vallejo]

... which means, device-tree.c stops requiring strictly CONFIG_HAS_DEVICE_TREE
and may function without it.

Not a functional change on architectures that currently use these files,
as they already select CONFIG_HAS_DEVICE_TREE.

Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
 xen/common/device-tree/device-tree.c | 2 ++
 xen/include/xen/device_tree.h        | 4 ++++
 2 files changed, 6 insertions(+)

diff --git a/xen/common/device-tree/device-tree.c b/xen/common/device-tree/device-tree.c
index 886e6c7712..c8a9c0e46a 100644
--- a/xen/common/device-tree/device-tree.c
+++ b/xen/common/device-tree/device-tree.c
@@ -2028,9 +2028,11 @@ static unsigned long unflatten_dt_node(const void *fdt,
             ((char *)pp->value)[sz - 1] = 0;
             dt_dprintk("fixed up name for %s -> %s\n", pathp,
                        (char *)pp->value);
+#ifdef CONFIG_HAS_DEVICE_TREE
             /* Generic device initialization */
             np->dev.type = DEV_DT;
             np->dev.of_node = np;
+#endif /* CONFIG_HAS_DEVICE_TREE */
         }
     }
     if ( allnextpp )
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 7d1c8bc305..641f24518d 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -109,9 +109,12 @@ struct dt_device_node {
      */
     struct list_head domain_list;
 
+#ifdef CONFIG_HAS_DEVICE_TREE
     struct device dev;
+#endif /* CONFIG_HAS_DEVICE_TREE */
 };
 
+#ifdef CONFIG_HAS_DEVICE_TREE
 #define dt_to_dev(dt_node)  (&(dt_node)->dev)
 
 static inline struct dt_device_node *dev_to_dt(struct device *dev)
@@ -120,6 +123,7 @@ static inline struct dt_device_node *dev_to_dt(struct device *dev)
 
     return container_of(dev, struct dt_device_node, dev);
 }
+#endif /* CONFIG_HAS_DEVICE_TREE */
 
 #define MAX_PHANDLE_ARGS 16
 struct dt_phandle_args {
-- 
2.43.0

[PATCH 18/19] xen/dt: Allow CONFIG_DOM0LESS_BOOT to include device-tree/

[Alejandro Vallejo]

... without CONFIG_HAS_DEVICE_TREE

Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
 xen/common/Kconfig              | 1 +
 xen/common/Makefile             | 2 +-
 xen/common/device-tree/Makefile | 8 ++++----
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 0951d4c2f2..353ccbd06f 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -14,6 +14,7 @@ config CORE_PARKING
 
 config DOM0LESS_BOOT
 	bool "Dom0less boot support" if EXPERT
+	select LIBFDT
 	depends on HAS_DOM0LESS && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS
 	default y
 	help
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 98f0873056..2717c81f9c 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -8,7 +8,7 @@ obj-y += cpu.o
 obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += device.o
 obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
-obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/
+obj-$(firstword $(CONFIG_HAS_DEVICE_TREE) $(CONFIG_DOM0LESS_BOOT)) += device-tree/
 obj-$(CONFIG_IOREQ_SERVER) += dm.o
 obj-y += domain.o
 obj-y += event_2l.o
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index 922c5bba9b..4c09e3fb2d 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1,10 +1,10 @@
 obj-y += bootfdt.init.o
-obj-y += bootinfo-fdt.init.o
-obj-y += bootinfo.init.o
-obj-y += device-tree.o
+obj-$(CONFIG_HAS_DEVICE_TREE) += bootinfo-fdt.init.o
+obj-$(CONFIG_HAS_DEVICE_TREE) += bootinfo.init.o
+obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o
 obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
 obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
-obj-y += intc.o
+obj-$(CONFIG_HAS_DEVICE_TREE) += intc.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
 obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o
-- 
2.43.0

[PATCH 19/19] kconfig: Allow x86 to pick CONFIG_DOM0LESS_BOOT

[Alejandro Vallejo]

Without picking CONFIG_HAS_DEVICE_TREE.

In order to do that. Allow CONFIG_DOM0LESS_BOOT to take include a subset
of the common/device-tree/ directory. x86 doesn't want dom0less-build.c,
as that's tightly integrated still to the ARM way of building domains.

Requires "unsupported" for the time being until all required patches
make it through.

Only intended as a functional change for x86.

Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
I'm compiling out dom0less-build.c because it relies heavily on
bootinfo. Initially x86 will keep its private builder even for
multidomain boots. And will do so until boot_info and bootinfo are
properly unified.

---
 xen/arch/x86/Kconfig            | 1 +
 xen/common/Kconfig              | 8 +++++---
 xen/common/device-tree/Makefile | 2 +-
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 7afe879710..4344b4289c 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -18,6 +18,7 @@ config X86
 	select HAS_COMPAT
 	select HAS_CPUFREQ
 	select HAS_DIT
+	select HAS_DOM0LESS
 	select HAS_EHCI
 	select HAS_EX_TABLE
 	select HAS_FAST_MULTIPLY
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 353ccbd06f..6e66657550 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -13,15 +13,17 @@ config CORE_PARKING
 	depends on NR_CPUS > 1
 
 config DOM0LESS_BOOT
-	bool "Dom0less boot support" if EXPERT
+	bool "Dom0less boot support" if EXPERT && (!X86 || UNSUPPORTED)
 	select LIBFDT
-	depends on HAS_DOM0LESS && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS
-	default y
+	depends on HAS_DOM0LESS && (X86 || (HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS))
+	default y if !X86
 	help
 	  Dom0less boot support enables Xen to create and start domU guests during
 	  Xen boot without the need of a control domain (Dom0), which could be
 	  present anyway.
 
+	  If unsure on x86, say N.
+
 config DOMAIN_BUILD_HELPERS
 	bool
 
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index 4c09e3fb2d..49d061733e 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -3,7 +3,7 @@ obj-$(CONFIG_HAS_DEVICE_TREE) += bootinfo-fdt.init.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += bootinfo.init.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o
-obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
+obj-$(filter-out $(CONFIG_X86),$(CONFIG_DOM0LESS_BOOT)) += dom0less-build.init.o
 obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += intc.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
-- 
2.43.0