The logic would be more robust disabling SMAP based on its precense in CR4,
rather than SMAP's accociation with a synthetic feature.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Fedora 29 is long out of date. Move forward 5 years to Fedora 40.
Include all the usual improvements. Rework the container to be non-root, use
heredocs for legibility, and switch to the new naming scheme.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Javi Merino <javi.merino@cloud.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
On Fedora 40, the build fails with:
In file included from domain_getinfo_stubs_v1.c:10:
domain_getinfo_stubs_v1.c: In function 'xsd_glue_failwith':
/usr/lib64/ocaml/caml/memory.h:275:29: error: unused variable 'caml__frame' [-Werror=unused-variable]
275 | struct caml__roots_block *caml__frame = *caml_local_roots_ptr
| ^~~~~~~~~~~
domain_getinfo_stubs_v1.c:48:9: note: in expansion of macro 'CAMLparam0'
48 | CAMLparam0();
| ^~~~~~~~~~
cc1: all warnings being treated as errors
The CAMLparam0 macro is defined in /usr/lib64/ocaml/caml/memory.h:255 as:
#define CAMLparam0() \
struct caml__roots_block** caml_local_roots_ptr = \
(DO_CHECK_CAML_STATE ? Caml_check_caml_state() : (void)0, \
&CAML_LOCAL_ROOTS); \
struct caml__roots_block *caml__frame = *caml_local_roots_ptr
We can't modify the macro. But, it turns out there's a CAMLnoreturn macro
with the sole purpose of masking this warning.
Fixes: a6576011a4 ("ocaml/libs: Implement a dynamically-loaded plugin for Xenctrl.domain_getinfo")
Signed-off-by: Javi Merino <javi.merino@cloud.com>
Acked-by: Christian Lindig <christian.lindig@cloud.com>
An initial step towards a non-multiboot internal representation of boot
modules for common code, starting with x86 setup and converting the fields
that are accessed for the startup calculations.
Introduce a new header, <asm/bootinfo.h>, and populate it with a new boot_info
structure initially containing a count of the number of boot modules.
No functional change intended.
Signed-off-by: Christopher Clark <christopher.w.clark@gmail.com>
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
If a partial DT has a /gic node, but no references to it, dtc may omit
the phandle property. With the phandle property missing,
fdt_get_phandle() returns 0, leading Xen to generate a malformed domU
dtb due to invalid interrupt-parent phandle references. 0 is an invalid
phandle value. Add a zero check, and fall back to GUEST_PHANDLE_GIC.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The code is DT specific and as such should be placed under common
directory for DT related files. Update MAINTAINERS file accordingly
and drop the line with a path from a top-level comment in dt-overlay.c.
It serves no purpose and requires being updated on every code movement.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Most of Xen is built with a stack alignment of 8 bytes, but the UEFI spec
mandates 16 and UEFI services will fault if the stack is misaligned.
While the caller of efi_multiboot2_prelude() takes care to align the stack,
mbi2.c accidentally got the Xen-wide default of 8, and has a 50% chance of
crashing depending on how many variables the compiler decided to spill to the
stack.
Compile mbi2.c with the appropriate alignment for UEFI functionality.
Also take the opportunity to make it a fully .init object.
Fixes: eb21ce14d7 ('x86/boot: Rewrite EFI/MBI2 code partly in C')
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
[rewrite the commit message]
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
domctl.h and sysctl.h have an interface version, which needs to be
bumped in case of incompatible modifications of the interface.
In order to avoid misunderstandings, add a comment to both headers
specifying in which cases a bump is needed.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Broken out of the subsequent patch for clarity.
* Rename head-bin-objs to obj32
* Use a .32.o suffix to distinguish these objects
* Factor out $(LD32)
No functional change.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
IVMD table contains restrictions about memory which must be mandatory assigned
to devices (and which permissions it should use), or memory that should be
never accessible to devices.
Some hardware however contains ranges in IVMD that reference devices outside of
the IVHD tables (in other words, devices not behind any IOMMU). Such mismatch
will cause Xen to fail in register_range_for_device(), ultimately leading to
the IOMMU being disabled, and Xen crashing as x2APIC support might be already
enabled and relying on the IOMMU functionality.
Relax IVMD parsing: allow IVMD blocks to reference devices not assigned to any
IOMMU. It's impossible for Xen to fulfill the requirement in the IVMD block if
the device is not behind any IOMMU, but it's no worse than booting without
IOMMU support, and thus not parsing ACPI IVRS in the first place.
Reported-by: Willi Junga <xenproject@ymy.be>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Receive Xen's command line passed by DTB using boot_fdt_cmdline()
and passed it to cmdline_parse() for further procesinng and setup
of Xen-specific parameters.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Parse DTB during startup, allowing memory banks and reserved
memory regions to be set up, along with early device tree node
(chosen, "xen,domain", "reserved-memory", etc) handling.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Remove the device initialization code from `xen/arch/arm/device.c`
and move it to the common code to avoid duplication and make it accessible
for both ARM and other architectures.
device_get_class(), device_init(), _sdevice[] and _edevice[] are wrapped by
"#ifdef CONFIG_HAS_DEVICE_TREE" for the case if an arch doesn't support
device tree.
Remove unnecessary inclusions of <asm/device.h> and <xen/init.h> from
`xen/arch/arm/device.c` as no code in the file relies on these headers.
Fix the inclusion order by moving <asm/setup.h> after <xen/*> headers to
resolve a compilation error:
./include/public/xen.h:968:35: error: unknown type name 'uint64_t'
968 | __DEFINE_XEN_GUEST_HANDLE(uint64, uint64_t);
| ^~~~~~~~
./include/public/arch-arm.h:191:21: note: in definition of macro '___DEFINE_XEN_GUEST_HANDLE'
191 | typedef union { type *p; uint64_aligned_t q; } \
| ^~~~
./include/public/xen.h:968:1: note: in expansion of macro '__DEFINE_XEN_GUEST_HANDLE'
968 | __DEFINE_XEN_GUEST_HANDLE(uint64, uint64_t);
because <asm/setup.h> includes <public/version.h>, which in turn includes
"xen.h", which requires <xen/types.h> to be processed correctly.
Additionally, add <xen/device_tree.h> to `device.c` as functions from this
header are used within the file.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Introduce a new `.dev.info` section in the RISC-V linker script to
handle device-specific information. This section is required by
common code (common/device.c: device_init(), device_get_class() ).
This section is aligned to `POINTER_ALIGN`, with `_sdevice` and `_edevice`
marking the start and end of the section, respectively.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Introduce a new `.dev.info` section in the PPC linker script to
handle device-specific information. This section is required by
common code (common/device.c: device_init(), device_get_class() ).
This section is aligned to `POINTER_ALIGN`, with `_sdevice` and `_edevice`
marking the start and end of the section, respectively.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Shawn Anastasio <sanastasio@raptorengineering.com>
Refactor arm/xen.lds.S by replacing the inline definitions for
device info sections with the newly introduced {DT,ACPI}_DEV_INFO
macros from xen/xen.lds.h.
Change alignment of DT_DEV_INFO and ACPI_DEV_INFO sections from
8 to POINTER_ALIGN as struct acpi_device_desc and struct device_desc
don't have any uint64_t's so it is safe to do that.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Introduce macros to define device information sections based on
the configuration of ACPI or device tree support. These sections
are required for common code of device initialization and getting
an information about a device.
These macros are expected to be used across different
architectures (Arm, PPC, RISC-V), so they are moved to
the common xen/xen.lds.h, based on their original definition
in Arm.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Introduce DECL_SECTION_WITH_LADDR in order to signal whether
DECL_SECTION() should specify a load address or not.
Update {ppc,x86}/xen.lds.S to use DECL_SECTION_WITH_LADDR.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
UBSAN complains:
(XEN) ================================================================================
(XEN) UBSAN: Undefined behaviour in common/spinlock.c:794:10
(XEN) load of address ffff82d040ae24c8 with insufficient space
(XEN) for an object of type 'struct lock_profile *'
(XEN) ----[ Xen-4.20-unstable x86_64 debug=y ubsan=y Tainted: C ]----
This shows up with GCC-14, but not with GCC-12. I have not bisected further.
Either way, the types for __lock_profile_{start,end} are incorrect.
They are an array of struct lock_profile pointers. Correct the extern's
types, and adjust the loop to match.
No practical change.
Reported-by: Andreas Glashauser <ag@andreasglashauser.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Today the build of Xenstore stubdoms depend on libxenguest just because
libxenguest depends on all needed libraries. In reality there is no
dependency on libxenguest for Xenstore stubdoms.
Use the actual dependencies instead.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Today the xenstored Makefile contains an unneeded reference to the
not used libxenguest library.
Remove it.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Printing I/O memory rangeset ranges in decimal is not very helpful when
debugging, so switch to hex by adding RANGESETF_prettyprint_hex flag
for iomem_ranges rangeset.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Assumption stated in the comments as if fdt_for_each_subnode() checks
for parent < 0 is utterly wrong. If parent is < 0, node offset is set to
0 (i.e. the very first node in the tree) and the loop's body is executed.
This incorrect assumption causes overlay_node_count() to also count nodes
that do not have __overlay__ as their subnode. The same story goes for
overlay_get_nodes_info(), where we end up requiring each node directly
under root node to have "target-path" set. DTBOs can specify other nodes
including special ones like __symbols__, __fixups__ that can be left to
reduce the number of steps a user needs to do to when it comes to invalid
phandles.
Fix it by adding checks if overlay < 0 after respective calls to
fdt_subnode_offset().
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Even though in most cases device nodes are not present directly under
the root node, it's a perfectly valid configuration (e.g. Qemu virt
machine dtb). At the moment, we don't handle this scenario which leads
to unconditional addition of extra leading '/' in the node full path.
This makes the attempt to add such device overlay to fail.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The assumption stated in the comment that the code will never get there
is incorrect. In overlay_get_nodes_info() we manually combine path from
target-path property with the node path by adding '/' as a separator.
This can differ from a path obtained by libfdt due to more advanced
logic used there which can for instance get rid of excessive slashes.
In case of incorrect target-path (e.g. target-path = "//axi"), the
comparison in dt_find_node_by_path_from() can fail triggering the assert
in debug builds.
Fixes: 0c0facdab6 ("xen/arm: Implement device tree node addition functionalities")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Julien Grall <jgrall@amazon.com>
With CONFIG_OVERLAY_DTB=y, unflatten_dt_alloc() is used as part of
unflatten_dt_node() used during runtime. In case of a binary compiled
such as unflatten_dt_alloc() does not get inlined (e.g. using -Og),
attempt to add an overlay to Xen (xl dt-overlay add) results in a crash.
(XEN) Instruction Abort Trap. Syndrome=0x7
(XEN) Walking Hypervisor VA 0xa00002c8cc0 on CPU2 via TTBR 0x0000000040340000
(XEN) 0TH[0x014] = 0x4033ff7f
(XEN) 1ST[0x000] = 0x4033ef7f
(XEN) 2ND[0x001] = 0x4000004033af7f
(XEN) 3RD[0x0c8] = 0x0
(XEN) CPU2: Unexpected Trap: Instruction Abort
(XEN) ----[ Xen-4.20-unstable arm64 debug=y Not tainted ]----
...
(XEN) Xen call trace:
(XEN) [<00000a00002c8cc0>] 00000a00002c8cc0 (PC)
(XEN) [<00000a0000202410>] device-tree.c#unflatten_dt_node+0xd0/0x504 (LR)
(XEN) [<00000a0000204484>] unflatten_device_tree+0x54/0x1a0
(XEN) [<00000a000020800c>] dt-overlay.c#handle_add_overlay_nodes+0x290/0x3d4
(XEN) [<00000a0000208360>] dt_overlay_sysctl+0x8c/0x110
(XEN) [<00000a000027714c>] arch_do_sysctl+0x1c/0x2c
Fixes: 9e9d2c079d ("xen/arm/device: Remove __init from function type")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Attempt to attach an overlay (xl dt-overlay attach) to a domain without
first adding this overlay to Xen (xl dt-overlay add) results in an
overlay track entry being NULL in handle_attach_overlay_nodes(). This
leads to NULL pointer dereference and the following data abort crash:
(XEN) Cannot find any matching tracker with input dtbo. Operation is supported only for prior added dtbo.
(XEN) Data Abort Trap. Syndrome=0x5
(XEN) Walking Hypervisor VA 0x40 on CPU0 via TTBR 0x0000000046948000
(XEN) 0TH[0x000] = 0x46940f7f
(XEN) 1ST[0x000] = 0x0
(XEN) CPU0: Unexpected Trap: Data Abort
(XEN) ----[ Xen-4.20-unstable arm64 debug=y Not tainted ]----
...
(XEN) Xen call trace:
(XEN) [<00000a0000208b30>] dt_overlay_domctl+0x304/0x370 (PC)
(XEN) [<00000a0000208b30>] dt_overlay_domctl+0x304/0x370 (LR)
(XEN) [<00000a0000274b7c>] arch_do_domctl+0x48/0x328
Fixes: 4c733873b5 ("xen/arm: Add XEN_DOMCTL_dt_overlay and device attachment to domains")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Today Mini-OS can only be configured to use all or no Xen libraries.
In order to prepare a more fine grained configuration scheme, add per
library config items to the Mini-OS config files.
As some libraries pull in others, the config files need to be
extended at build time to reflect those indirect library uses.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
xsd_glue_dev packaging is inconsistent with the rest of OCaml packages and
isn't actually necessary. The .a is needed alongside compiled bytecode files
during linking and was missed in the initial oxenstored plugin work.
Specify OCAMLCFLAGS along with OCAMLOPTFLAGS.
Signed-off-by: Andrii Sultanov <andrii.sultanov@cloud.com>
Acked-by: Christian Lindig <christian.lindig@cloud.com>
Avoid using BOOTMOD_XEN region for other purposes or boot modules
which could result in memory corruption or undefined behaviour.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Use virt_to_maddr() instead of LINK_TO_LOAD as virt_to_maddr()
covers all the cases where LINK_TO_LOAD() is used.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Implement the virt_to_maddr() function to convert virtual addresses
to machine addresses. The function includes checks for valid address
ranges, specifically the direct mapping region (DIRECTMAP_VIRT_START)
and the Xen's Linkage (XEN_VIRT_START) region. If the virtual address
falls outside of these regions, an assertion will trigger.
To implement this, the phys_offset variable is made accessible
outside of riscv/mm.c.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
It's not unnecessary (as the earlier commit claimed): The integrated
assembler of Clang up to 11 complains about an "invalid operand for
instruction".
Fixes: b42cf31d11 ("x86: use alternative_input() in cache_flush()")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
While doing this, factor out checks common to architectural and hidden
state.
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Andrei Cherechesu
Frediano Ziglio
Andrew Cooper
Javi Merino
Daniel P. Smith
Christopher Clark
Stewart Hildebrand
Michal Orzel
Jan Beulich
Marek Marczykowski-Górecki
Juergen Gross
Roger Pau Monné
Oleksii Kurochko
Federico Serafini
Andrii Sultanov
Alejandro Vallejo