Add the arguments that create_domain() takes to boot_domain. This creates
a consistent place to drop the outputs of the dom0less bindings.
Not a functional change. Later patches use these fields as the outputs of
the dom0less parsing functions.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Acked-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
It's meant to be usable by anyone with CONFIG_DOM0LESS_BOOT.
While moving, replace an inclusion of public/domctl.h by a forward
declaration.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
This allows bootfdt.c and device-tree.c to be usable without
CONFIG_HAS_DEVICE_TREE_DISCOVERY.
Gate everything else on CONFIG_HAS_DEVICE_TREE_DISCOVERY.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Architectures that don't discover devices via DT may skip anything to
do with device_t during the DT unflattening phase. Make device-tree.c
stop requiring CONFIG_HAS_DEVICE_TREE_DISCOVERY so it may function with
CONFIG_DEVICE_TREE_PARSE alone.
This allows CONFIG_DEVICE_TREE_PARSE to unflatten a DT ignoring its
devices if CONFIG_HAS_DEVICE_TREE_DISCOVERY is not selected.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Moving forward the idea is for there to be:
1. Basic DT support: used by dom0less/hyperlaunch.
2. Full DT support: used for device discovery and HW setup.
Rename HAS_DEVICE_TREE to HAS_DEVICE_TREE_DISCOVERY to describe (2) and
create a new DEVICE_TREE_PARSE to describe (1).
Have DEVICE_TREE_PARSE selected by both HAS_DEVICE_TREE_DISCOVERY and
DOM0LESS_BOOT.
Add a dependency on STATIC_MEMORY for discovery, as it relies on
the memory map itself being described on the DTB.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com> #iommu
Reviewed-by: Oleksii Kurochko<oleksii.kurochko@gmail.com> # riscv
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
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 <alejandro.garciavallejo@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Move all functions independent of "struct bootinfo" back to bootfdt.c
Not a functional change.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
bootinfo-fdt.c 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 <alejandro.garciavallejo@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
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 <alejandro.garciavallejo@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Oleksii Kurochko<oleksii.kurochko@gmail.com> # riscv
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 <alejandro.garciavallejo@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Oleksii Kurochko<oleksii.kurochko@gmail.com> # riscv
Create a struct field within kernel_info with the contents common to
kernel_info and boot_domain, and define that field in common code. This
enables x86 to use that field as-is and drop x86's boot_domain.
Note that x86 mutates the module when releasing it, calculating headroom,
etc. So they must be made non-const on move.
Not a functional change.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
These types resemble each other very closely in layout and intent,
and with "struct boot_module" already in common code it makes perfect
sense to merge them. In order to do so, rename identical fields with
conflicting names.
While doing this, s/BOOTMOD_XSM/BOOTMOD_XSM_POLICY/, as it was on x86.
XSM doesn't support external modules, so don't let the name imply it
through ambiguity.
No functional change intended.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Later patches extract the bindings to a separate file, where that global
won't be available. Make the check when calling the function instead so
the bindings remain agnostic.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
llc_colors_str being outside the main loop makes domains without
explicit coloring inherit the colors of the last colored domain parsed.
Move it inside so that's no longer the case.
Fixes: 5948dc16759c("xen/arm: add support for cache coloring...")
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
... based on CONFIG_X86. x86 won't depend on it, and it'll only be used
by the domain builder in common/device-tree/
Moving it to an arch-specific subfield (as introduced in a later patch)
is unwieldy, because all other arches depend on it.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Alejandro Vallejo