Commit e3ed540f2e was meant to make AMD_SVM dependent on AMD and
INTEL_VMX on INTEL. This dependency was reflected using 'if' next to a
prompt which is incorrect as it that deals only with the visibility of the
given Kconfig option. This makes it impossible to e.g. disable INTEL_VMX
when INTEL is disabled (option is hidden). Fix it while keeping the
possibility of e.g. enabling INTEL_VMX when INTEL is disabled.
Fixes: e3ed540f2e ("x86/hvm: add HVM-specific Kconfig")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
While technically possible to support live-patching on MPU systems, today
the code depends on vmap. However, this relationship is not reflected in
Kconfig and allows to enable live-patching on MPU, where HAS_VMAP is not
selected.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
HAS_PASSTHROUGH should only be selected on MMU systems. It's been like
that until commit 163c6b5898 added possibility to select HAS_PASSTHROUGH
if PCI_PASSTHROUGH is enabled on Arm64. This is incorrect as it may result
in enabling passthrough/ build on MPU systems. PCI_PASSTHROUGH should
depend on HAS_PASSTHROUGH instead.
Fixes: 163c6b5898 ("xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Trying to boot a compressed kernel with UBSAN enabled, results in the
following warning:
(XEN) UBSAN: Undefined behaviour in common/device-tree/kernel.c:21:12
(XEN) load of misaligned address 00000a0040f89867 for type 'uint32_t'
(XEN) which requires 4 byte alignment
...
(XEN) [<00000a0000529964>] kernel_decompress+0x2bc/0x5bc
(XEN) [<00000a000052a354>] kernel_probe+0x6f0/0x734
(XEN) [<00000a0000528714>] dom0less-build.c#construct_domU+0x188/0x9d8
If &image[image_len - 4] is not aligned to 4B boundary it causes
unaligned access which is undefined behavior on Arm. Use memcpy instead
to be safe.
Fixes: c1be0b102e ("xen/arm: support gzip compressed kernels")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>
The current look and feel of setup_mm() leaves a lot to be desired. The
scope of variables is not the best, many variables are not really needed
while some others are set but not used. The first iteration of membanks
is split from the loop for no reason. Tidy up this function for better
readability.
No functional change.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Hari Limaye <hari.limaye@arm.com>
Tested-by: Hari Limaye <hari.limaye@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
When CONFIG_PDX_COMPRESSION=n, pdx_init_mask(), pdx_region_mask() and
pfn_pdx_hole_setup() are just stubs doing nothing. It does not make
sense to keep the two loops iterating over all the memory banks.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Hari Limaye <hari.limaye@arm.com>
Tested-by: Hari Limaye <hari.limaye@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Harden the code by panicing if direct map is too small for current memory
layout taking into account possible PDX compression. Otherwise the assert
is observed:
Assertion '(mfn_to_pdx(maddr_to_mfn(ma)) - directmap_base_pdx) < (DIRECTMAP_SIZE >> PAGE_SHIFT)' failed at ./arch/arm/include/asm/mmu/mm.h:72
At the moment, we don't set max_pdx denoting maximum usable PDX which
should be based on max_page. Consolidate setting of max_page and max_pdx
in init_pdx() for both arm32 and arm64. max_pdx will be used in the
future to set up frametable mappings respecting the PDX grouping.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Hari Limaye <hari.limaye@arm.com>
Tested-by: Hari Limaye <hari.limaye@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
At the moment, we unconditionally allocate space for grant table region
membank and add it in the membanks array to find_unallocated_memory() to
find unused memory. In case of CONFIG_GRANT_TABLE=n, the size of the
region is empty and assertion in rangeset_remove_range() fails when
booting hwdom or 1:1 domU without IOMMU. Example:
(XEN) Assertion 's <= e' failed at common/rangeset.c:189
...
(XEN) Xen call trace:
(XEN) [<00000a0000218b5c>] rangeset_remove_range+0xbc/0x2d4 (PC)
(XEN) [<00000a00002b8370>] find_unallocated_memory+0x140/0x208 (LR)
(XEN) [<00000a00002cc28c>] make_hypervisor_node+0x310/0x7e0
...
Same issue would occur when booting hwdom with LLC coloring enabled.
Fix it by performing conditional allocation and configuration.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Tested-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
After commit 4df2e99d73 ("console/serial: set the default transmit
buffer size in Kconfig"), the default value is set by Kconfig option
CONFIG_SERIAL_TX_BUFSIZE. Moreover it was bumped to 32KB by commit
d09e44e5d8 ("console/serial: bump buffer from 16K to 32K").
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Commit f6d1bfa160 introduced flushing conring in console_init_preirq().
However, when CONFIG_EARLY_PRINTK is enabled, the early boot messages
had already been sent to serial before main console initialization. This
results in all the early boot messages being duplicated.
Change conring_flush() to accept argument listing devices to which to
flush conring. We don't want to send to serial at console initialization
when using early printk, but we want these messages to be send at conring
dump triggered by keyhandler.
Fixes: f6d1bfa160 ("xen/console: introduce conring_flush()")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Fix the condition part of the for loop in p2m_invalidate_root() that
uses P2M_ROOT_LEVEL instead of P2M_ROOT_PAGES. The goal here is to
invalidate all root page tables (that can be concatenated), so the loop
must iterate through all these pages. Root level can be 0 or 1, whereas
there can be 1,2,8,16 root pages. The issue may lead to some pages
not being invalidated and therefore the guest access won't be trapped.
We use it to track pages accessed by guest for set/way emulation provided
no IOMMU, IOMMU not enabled for the domain or P2M not shared with IOMMU.
Fixes: 2148a125b7 ("xen/arm: Track page accessed between batch of Set/Way operations")
Reported-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
It hasn't been used since the introduction of the script. Also drop
relevant CFLAGS and header inclusion.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Depending on the build environment, HOSTCC can be different than CC. With
the recent `install` rule addition, this would put a binary of a wrong
format in the destdir (e.g. building tests on x86 host for Arm target).
Take the opportunity to adjust the `run` rule to only run the test if
HOSTCC is CC, else print a warning message.
Fixes: 96a587a057 ("tools/tests: Add install target for vPCI")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
This feature is arch agnostic, thus move it to common.
While at it, move xen/pfn.h inclusion in static-memory.h below #ifdef
CONFIG_STATIC_MEMORY when it is only needed.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
This is just a wrapper around fdt_begin_node(). Move it to common and
remove asm/domain_build.h inclusion from static-shmem.c.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
DOM0LESS_BOOT is sufficient (only Arm selects it today). If needed,
proper arch dependency can be introduced while adding support for it for
another architecture.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
There's nothing Arm specific about this feature. Move it to common as
part of a larger activity to commonalize device tree related features.
For now, select it only for ARM until others (e.g. RISC-V) verify it
works for them too.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Use the same license as the files from which the code originated during
recent code movements. Take the opportunity to add SPDX identifier for
device-tree.c and remove the license text.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Just like for RISCV and PPC, the earlier we enable the CI build the
better.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
There's no benefit in having process_shm_chosen() next to process_shm().
The former is just a helper to pass "/chosen" node to the latter for
hwdom case. Drop process_shm_chosen() and instead use process_shm()
passing NULL as node parameter, which will result in searching for and
using /chosen to find shm node (the DT full path search is done in
process_shm() to avoid expensive lookup if !CONFIG_STATIC_SHM). This
will simplify future handling of hw/control domain separation.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Static shared memory requires device-tree boot. At the moment, booting
with ACPI enabled and CONFIG_STATIC_SHM=y results in a data abort when
dereferencing node in process_shm() because dt_host is always NULL.
Fixes: 09c0a8976a ("xen/arm: enable statically shared memory on Dom0")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
As reported by ECLAIR scan, MISRA requires declaration to be visible
(R8.4). This is not the case for ioremap().
Fixes: 2cd02c27d3 ("arm/mpu: Implement stubs for ioremap_attr on MPU")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
When purging old-style annotations, MPU code was left unmodified. Fix
it.
Fixes: 221c66f4f2 ("Arm: purge ENTRY(), ENDPROC(), and ALIGN")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
ArmV8-R AArch32 does not support LPAE. The reason being PMSAv8-32
supports 32-bit physical address only.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
We are missing a way to detect whether a user provided a value for
nr_spis equal to 0 or did not provide any value (default is also 0) which
can cause issues when calculated nr_spis is > 0 and the value from domain
config is 0. Fix it by setting default value for nr_spis to newly added
LIBXL_NR_SPIS_DEFAULT i.e. UINT32_MAX (max supported nr of SPIs is 960
anyway).
Fixes: 55d62b8d46 ("tools/arm: Reject configuration with incorrect nr_spis value")
Reported-by: Luca Fancellu <luca.fancellu@arm.com>
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
If the calculated value for nr_spis by the toolstack is bigger than the
value provided by the user, we silently ignore the latter. This is not
consistent with the approach we have in Xen on Arm when we try to reject
incorrect configuration. Also, the documentation for nr_spis is
incorrect as it mentions 991 as the number of max SPIs, where it should
be 960 i.e. (1020 - 32) rounded down to the nearest multiple of 32.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
At the moment, we print a warning about max number of IRQs supported by
GIC bigger than vGIC only for hardware domain. This check is not hwdom
special, and should be made common. Also, in case of user not specifying
nr_spis for dom0less domUs, we should take into account max number of
IRQs supported by vGIC if it's smaller than for GIC.
Introduce VGIC_MAX_IRQS macro and use it instead of hardcoded 992 value.
Introduce VGIC_DEF_NR_SPIS macro to store the default number of vGIC SPIs.
Fix calculation of nr_spis for dom0less domUs and make the GIC/vGIC max
IRQs comparison common.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
These functions are generic and used not only for hardware domain. This
creates confusion when printing any of these panic messages (e.g.
failure when loading domU kernel would result in informing a user about
a failure in loading hwdom kernel).
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Value stored in size_cells is never read because we're only interested
in retrieving gbase address of shmem region for which we only need
address cells.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
fdt_finish_reservemap() may fail (with -FDT_ERR_NOSPACE) in which case
further DTB creation (in prepare_dtb_hwdom()) makes no sense. Fix it.
Fixes: 13bb63b754 ("device tree,arm: supply a flat device tree to dom0")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
XEN_DMOP_set_irq_level operation requires elements of pad array (being
member of xen_dm_op_set_irq_level structure) to be 0. While handling the
hypercall we validate this. If one of the elements is not zero, we set
rc to -EINVAL. At this point we should stop further DM handling and bail
out propagating the error to the caller. However, instead of goto the
code uses break which has basically no meaningful effect. The rc value
is never read and the code continues with the hypercall processing ending
up (possibly) with the interrupt injection. Fix it.
Fixes: 5d752df85f ("xen/dm: Introduce xendevicemodel_set_irq_level DM op")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
At the moment the GIC node we create for hwdom has a name
"interrupt-controller". Change it so that we use the same name as the
GIC node from host device tree. This is done for at least 2 purposes:
1) The convention in DT spec is that a node name with "reg" property
is formed "node-name@unit-address".
2) With DT overlay feature, many overlays refer to the GIC node using
the symbol under __symbols__ that we copy to hwdom 1:1. With the name
changed, the symbol is no longer valid and requires error prone manual
change by the user.
The unit-address part of the node name always refers to the first
address in the "reg" property which in case of GIC, always refers to
GICD and hwdom uses host memory layout.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
On Arm32, when CONFIG_PHYS_ADDR_T_32 is set, a build failure is observed:
arch/arm/platforms/vexpress.c: In function 'vexpress_smp_init':
arch/arm/platforms/vexpress.c:102:12: error: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'long long unsigned int' [-Werror=format=]
102 | printk("Set SYS_FLAGS to %"PRIpaddr" (%p)\n",
When CONFIG_PHYS_ADDR_T_32 is set, paddr_t is defined as unsigned long.
Commit 96f35de69e dropped __virt_to_maddr() which used paddr_t as a
return type. Without a cast, the expression type is unsigned long long
which causes the issue. Fix it.
Fixes: 96f35de69e ("x86+Arm: drop (rename) __virt_to_maddr() / __maddr_to_virt()")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Tested-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
On Arm32, when CONFIG_PHYS_ADDR_T_32 is set, a build failure is observed:
common/device-tree/bootfdt.c: In function 'build_assertions':
./include/xen/macros.h:47:31: error: static assertion failed: "!(alignof(struct membanks) != 8)"
47 | #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond ")"); })
| ^~~~~~~~~~~~~~
common/device-tree/bootfdt.c:31:5: note: in expansion of macro 'BUILD_BUG_ON'
31 | BUILD_BUG_ON(alignof(struct membanks) != 8);
When CONFIG_PHYS_ADDR_T_32 is set, paddr_t is defined as unsigned long,
therefore the struct membanks alignment is 4B and not 8B. The check is
there to ensure the struct membanks and struct membank, which is a
member of the former, are equally aligned. Therefore modify the check to
compare alignments obtained via alignof not to rely on hardcoded
values.
Fixes: 2209c1e35b ("xen/arm: Introduce a generic way to access memory bank structures")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Tested-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Julien Grall <julien@xen.org>
In the original patch e7a80636f1 ("xen/arm: add cache coloring support
for Xen image"), the stub was added under wrong assumption that DCE
won't remove the function call if it's not static. This assumption is
incorrect as we already rely on DCE for cases like this one. Therefore
drop the stub, that otherwise would be a place potentially prone to
errors in the future.
Suggested-by: Julien Grall <julien@xen.org>
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Addition of FLASK permission for this hypercall was overlooked in the
original patch. Fix it. Setting LLC colors is only possible during domain
creation.
Fixes: 6985aa5e0c ("xen: extend domctl interface for cache coloring")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Addition of FLASK permission for this hypercall was overlooked in the
original patch. Fix it. The only dt overlay operation is attaching that can
happen only after the domain is created. Dom0 can attach overlay to itself
as well.
Fixes: 4c733873b5 ("xen/arm: Add XEN_DOMCTL_dt_overlay and device attachment to domains")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Addition of FLASK permission for this hypercall was overlooked in the
original patch. Fix it. The only VUART operation is initialization that
can occur only during domain creation.
Fixes: 86039f2e8c ("xen/arm: vpl011: Add a new domctl API to initialize vpl011")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
It's definitely worth mentioning as one of the most notable feature on
Arm this release.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
At the moment, find_unallocated_memory() is only used to retrieve free
memory ranges for direct mapped domains in order to find extended
regions. It is not generic as it makes assumptions as for the place at
which it's being called (domain memory already allocated, gnttab region
already found) and hardcodes the memory banks to be excluded.
Make the function more generic, so that it can be used for other
purposes whenever there is a need to find free host memory regions (e.g.
upcoming LLC coloring series). Allow passing array with memory banks as a
parameter together with a callback to populate free regions structure,
as the logic may differ depending on the needs.
Add find_host_extended_regions() to be called from make_hypervisor_node()
to contain the logic to find extended regions for domains using host
memory layout that are not permitted to use IOMMU.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Tested-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Commit a14593e399 extended BOOTINFO_{ACPI,SHMEM}_INIT initializers
list with a new 'type' member but forgot to add trailing commas (they
were present before). This results in a build failure when building
with CONFIG_ACPI=y and CONFIG_STATIC_SHM=y:
./include/xen/bootfdt.h:155:5: error: request for member 'shmem' in something not a structure or union
155 | .shmem.common.max_banks = NR_SHMEM_BANKS, \
| ^
./include/xen/bootfdt.h:168:5: note: in expansion of macro 'BOOTINFO_SHMEM_INIT'
168 | BOOTINFO_SHMEM_INIT \
| ^~~~~~~~~~~~~~~~~~~
common/device-tree/bootinfo.c:22:39: note: in expansion of macro 'BOOTINFO_INIT'
22 | struct bootinfo __initdata bootinfo = BOOTINFO_INIT;
Fixes: a14593e399 ("xen/device-tree: Allow region overlapping with /memreserve/ ranges")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
At the moment, when printing memory ranges during early boot, endpoints
of some ranges are printed as inclusive (RAM, RESVD, SHMEM) and some
as exclusive (Initrd, MODULE). Make the behavior consistent and print
all the endpoints as inclusive.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-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>
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>
AoU are the assumptions that Xen relies on other components (eg platform
platform, domains) to fulfill its requirements. In our case, platform means
a combination of hardware, firmware and bootloader.
We have defined AoU in the intro.rst and added AoU for the generic
timer.
Also, fixed a requirement to denote that Xen shall **not** expose the
system counter frequency via the "clock-frequency" device tree property.
The reason being the device tree documentation strongly discourages the
use of this peoperty. Further if the "clock-frequency" is exposed, then
it overrides the value programmed in the CNTFRQ_EL0 register.
So, the frequency shall be exposed via the CNTFRQ_EL0 register only and
consequently there is an assumption on the platform to program the
register correctly.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
SMR masking support allows deriving a mask either using a 2-cell iommu
specifier (per master) or stream-match-mask SMMU dt property (global
config). Even though the mask is stored in the fwid when adding a
device (in arm_smmu_dt_xlate_generic()), we still set it to 0 when
allocating SMEs (in arm_smmu_master_alloc_smes()). So at the end, we
always ignore the mask when programming SMRn registers. This leads to
SMMU failures. Fix it by completing the support.
A bit of history:
Linux support for SMR allocation was mainly done with:
588888a7399d ("iommu/arm-smmu: Intelligent SMR allocation")
021bb8420d44 ("iommu/arm-smmu: Wire up generic configuration support")
Taking the mask into account in arm_smmu_master_alloc_smes() was added
as part of the second commit, although quite hidden in the thicket of
other changes. We backported only the first patch with: 0435784cc7
("xen/arm: smmuv1: Intelligent SMR allocation") but the changes to take
the mask into account were missed.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Rahul Singh <rahul.singh@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
According to GIC spec IHI 0069H.b (12.4.9), the ListRegs field of
ICH_VTR_EL2 can have value between 0b00000..0b01111, as there can
be maximum 16 LRs (field value + 1). Fix the mask used to extract this
value which wrongly assumes there can be 64 (case for GICv2).
Fixes: bc183a0235 ("xen/arm: Add support for GIC v3")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
As stated in README, the minimum supported GCC version for arm32 is
4.9, therefore drop the custom do_div() macro in favor of using the
optimized version.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Given no further use in C world of boot_phys_offset, drop it from the
argument list of start_xen() and do the necessary changes in the startup
code head.S (most notably modifying launch not to expect 2 arguments to
pass to C entry point).
Both on arm64 and arm32, phys offset (stored in x20 or r10 respectively)
is still needed, so that it can be used in e.g. create_table_entry,
therefore keep it on the list of common register usage.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
boot_phys_offset stores the physical offset (PA-VA), is calculated in
the startup head.S code and passed to start_xen() as a first argument.
There is no point in using it given that we can ask MMU to translate
a VA for us using e.g. virt_to_{mfn,maddr}. Drop usage of these
variables from the C world.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Memory node probing is done as part of early_scan_node() that is called
for each node with depth >= 1 (root node is at depth 0). According to
Devicetree Specification v0.4, chapter 3.4, /memory node can only exists
as a top level node. However, Xen incorrectly considers all the nodes with
unit node name "memory" as RAM. This buggy behavior can result in a
failure if there are other nodes in the device tree (at depth >= 2) with
"memory" as unit node name. An example can be a "memory@xxx" node under
/reserved-memory. Fix it by introducing device_tree_is_memory_node() to
perform all the required checks to assess if a node is a proper /memory
node.
Fixes: 3e99c95ba1 ("arm, device tree: parse the DTB for RAM location and size")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Tested-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Julien Grall <julien@xen.org>
Dom0less domain using host memory layout may use more than one
re-distributor region (d->arch.vgic.nr_regions > 1). In that case Xen
will add them in a "reg" property of a GICv3 domU node. Guest needs to
know how many regions to search for, and therefore the GICv3 dt binding
[1] specifies that "#redistributor-regions" property is required if more
than one redistributor region is present. However, Xen does not add this
property which makes guest believe, there is just one such region. This
can lead to guest boot failure when doing GIC SMP initialization. Fix it
by adding this property, which matches what we do for hwdom.
[1] Linux: Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
Fixes: 4809f9ec7d ("xen/arm: if direct-map domain use native addresses for GICv3")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
With Arm port being the major recipient of dt related patches and the
future need of incorporating dt support into other ports, we'd like to
keep an eye on these changes.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
As a follow up to commit cb1ddafdc5 ("xen/arm/static-shmem: Static-shmem
should be direct-mapped for direct-mapped domains") add a check to
request that both host and guest physical address must be supplied for
direct mapped domains. Otherwise return an error to prevent unwanted
behavior.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Fixes: 988f1c7e1f ("xen/arm: static-shmem: fix "gbase/pbase used uninitialized" build failure")
Reviewed-by: Julien Grall <jgrall@amazon.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Building Xen with CONFIG_STATIC_SHM=y results in a build failure:
arch/arm/static-shmem.c: In function 'process_shm':
arch/arm/static-shmem.c:327:41: error: 'gbase' may be used uninitialized [-Werror=maybe-uninitialized]
327 | if ( is_domain_direct_mapped(d) && (pbase != gbase) )
arch/arm/static-shmem.c:305:17: note: 'gbase' was declared here
305 | paddr_t gbase, pbase, psize;
This is because the commit cb1ddafdc5 adds a check referencing
gbase/pbase variables which were not yet assigned a value. Fix it.
Fixes: cb1ddafdc5 ("xen/arm/static-shmem: Static-shmem should be direct-mapped for direct-mapped domains")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
At the moment, all the Arm64 Qemu tests use GICv2 which is the default
GIC version used by Qemu. Improve the coverage by adding a new test in
which Qemu will be configured to have GICv3.
Rename host device tree name to "virt.dtb" to be GIC version agnostic.
Use "gic-version" Qemu option to select the version to use. Unless the
test variant is set to "gicv3", version 2 will be used.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Introduce qemu based Arm earlyprintk test and build jobs to cover this
feature in debug variant. The tests simply check for the presence of the
last message printed by the bootstrap code before entering the C world.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
To save some bandwith that can be later on used to increase the test
coverage by adding new tests, drop the following non-debug test/build
jobs existing in both debug and non-debug variants:
- static memory (arm64, arm32)
- static shared memory (arm64)
- static heap (arm64)
- boot cpupools (arm64)
- gzip (arm32)
More generic tests existing in both variants were left unmodified.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Since commit 6cd046c501 ("xen/arm: Enlarge identity map space to 10TB")
Xen can be loaded below 10 TiB. Update docs accordingly.
Take the opportunity to update stale links to Linux docs.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
These variables are useless. They are being assigned a value which is
never used since UART is expected to be pre-configured.
No functional change.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
On Arm we don't use console_{suspend,resume} and the corresponding
stubs in serial drivers are being redundantly copied whenever a new
driver is added. Drop them as well as useless .endboot = NULL assignment.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
After introduction of lock_evaluate_nospec() using bool type, building
Xen on Arm with UBSAN enabled fails:
In file included from ./include/xen/spinlock.h:4,
from common/ubsan/ubsan.c:13:
./include/xen/nospec.h:79:22: error: unknown type name ‘bool’
79 | static always_inline bool lock_evaluate_nospec(bool condition)
There is no issue on x86, as xen/stdbool.h is included somewhere along
the asm/nospec.h path, which is not the case for other architectures.
Fixes: 7ef0084418 ("x86/spinlock: introduce support for blocking speculation into critical regions")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Currently, if user enables HVC_DCC config option in Linux, it invokes access
to debug data transfer registers (i.e. DBGDTRTX_EL0 on arm64, DBGDTRTXINT on
arm32). As these registers are not emulated, Xen injects an undefined
exception to the guest and Linux crashes.
To prevent this crash, introduce a partial emulation of DBGDTR[TR]X_EL0
(these registers share the same encoding) as RAZ/WI and MDCCSR_EL0 as TXfull.
Refer ARM DDI 0487J.a ID042523, D19.3.8, DBGDTRTX_EL0
"If TXfull is set to 1, set DTRRX and DTRTX to UNKNOWN".
Thus, any OS is expected to read MDCCSR_EL0 and check for TXfull before
using DBGDTRTX_EL0. Linux does it via hvc_dcc_init() ---> hvc_dcc_check(),
and returns -ENODEV in case TXfull bit is still set after writing a test
character. This way we prevent the guest from making use of HVC DCC as a
console.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Since commit bd1001db0a ("xen/arm: arm32: Allow Xen to boot on
unidentified CPUs"), it's been possible to boot 32-bit Xen on ARMv8A CPUs
in AArch32 state (assuming HW supports EL2 execution in AArch32). Clarify
the support statement and mark it as Tech Preview, as this use case is
uncommon and hasn't really been tested/hardened.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Commit 4cac80e226 broke the CI cppcheck jobs by adding an entry for
a rule 20.12 with "Severity" and "Summary" fields placed in reverse order.
This leads to an error as reported by convert_misra_doc.py:
No summary for rule 20.12
Fixes: 4cac80e226 ("docs/misra/rules.rst: add rule 16.6 and 20.12")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Commit 0441c3acc7 forgot to rename FIXMAP_CONSOLE to FIX_CONSOLE in
TEMPORARY_EARLY_UART_VIRTUAL_ADDRESS macro. This results in a build
failure on arm32, when early printk is enabled:
arch/arm/arm32/mmu/head.S:311: Error: invalid operands (*UND* and *ABS* sections) for `*'
Fixes: 0441c3acc7 ("xen/arm: fixmap: Rename the fixmap slots to follow the x86 convention")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
At the moment, the hardware domain vUART is always compiled in. In the
spirit of fine granular configuration, make it optional so that the
feature can be disabled if not needed. This UART is not exposed (e.g.
via device tree) to a domain and is mostly used to support special use
cases like Linux early printk, prints from the decompressor code, etc.
Introduce Kconfig option CONFIG_HWDOM_VUART, enabled by default (to keep
the current behavior) and use it to protect the vUART related code.
Provide stubs for domain_vuart_{init,free}() in case the feature is
disabled. Take the opportunity to add a struct domain forward declaration
to vuart.h, so that the header is self contained.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Tested-by: Luca Fancellu <luca.fancellu@arm.com>
After removal of gdbstub by commit d182f9feae ("x86: Remove gdbstub"),
we no longer have users of serial_{put,get}c functions, so remove them.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
When running Xen on arm32, in scenario where Xen is loaded at an address
such as boot_phys_offset >= 2GB, UBSAN reports the following:
(XEN) UBSAN: Undefined behaviour in arch/arm/setup.c:739:58
(XEN) pointer operation underflowed 00200000 to 86800000
(XEN) Xen WARN at common/ubsan/ubsan.c:172
(XEN) ----[ Xen-4.19-unstable arm32 debug=y ubsan=y Not tainted ]----
...
(XEN) Xen call trace:
(XEN) [<0031b4c0>] ubsan.c#ubsan_epilogue+0x18/0xf0 (PC)
(XEN) [<0031d134>] __ubsan_handle_pointer_overflow+0xb8/0xd4 (LR)
(XEN) [<0031d134>] __ubsan_handle_pointer_overflow+0xb8/0xd4
(XEN) [<004d15a8>] start_xen+0xe0/0xbe0
(XEN) [<0020007c>] head.o#primary_switched+0x4/0x30
The failure is reported for the following line:
(paddr_t)(uintptr_t)(_start + boot_phys_offset)
This occurs because the compiler treats (ptr + size) with size bigger than
PTRDIFF_MAX as undefined behavior. To address this, switch to macro
virt_to_maddr(), given the future plans to eliminate boot_phys_offset.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Tested-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
At the moment, all Yocto jobs run on Arm64 runners. To address CI
capacity issues, move yocto-qemux86-64 job to x86. Reflect the change in
the makefile generating Yocto docker files and fix CONTAINER name
definition that incorrectly expects YOCTO_HOST variable to be set for x86
container as well, which does not have a platform name appended.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
At the moment, trying to run xencov read/reset (calling SYSCTL_coverage_op
under the hood) results in a crash. This is due to a profiler trying to
access data in the .init.* sections (libfdt for Arm and libelf for x86)
that are stripped after boot. Normally, the build system compiles any
*.init.o file without COV_FLAGS. However, these two libraries are
handled differently as sections will be renamed to init after linking.
To override COV_FLAGS to empty for these libraries, lib{fdt,elf}.o were
added to nocov-y. This worked until e321576f40 ("xen/build: start using
if_changed") that added lib{fdt,elf}-temp.o and their deps to extra-y.
This way, even though these objects appear as prerequisites of
lib{fdt,elf}.o and the settings should propagate to them, make can also
build them as a prerequisite of __build, in which case COV_FLAGS would
still have the unwanted flags. Fix it by switching to $(targets) instead.
Also, for libfdt, append libfdt.o to nocov-y only if CONFIG_OVERLAY_DTB
is not set. Otherwise, there is no section renaming and we should be able
to run the coverage.
Fixes: e321576f40 ("xen/build: start using if_changed")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Take an example from commit 1ec3fe1f66 ("xen/arm32: head: Improve
logging in head.S") to add support for printing early boot messages
while running on identity mapping:
- define PRINT_SECT() macro to be able to specify a section for storing
a string. PRINT() will use .rodata.str and PRINT_ID() - .rodata.idmap.
This is necessary, because when running on identity mapping, the
strings need to be part of the first page that is mapped,
- move loading a runtime virtual UART address right after enabling MMU
(the corresponding steps repeated in {primary,secondary}_switched are
now consolidated in a single place),
- move early printk 'hex' string into .rodata.idmap and replace 'adr'
instruction in asm_putn with 'adr_l' to extend the addressable range,
- remove RODATA_STR() macro given no use.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Thanks to 1ec3fe1f66 ("xen/arm32: head: Improve logging in head.S"),
we can now use PRINT_ID() macro to print messages when running on
identity mapping. For that, all the strings need to be part of the first
page that is mapped. This is not the case for a 'hex' string (used by
asm_putn when printing register values), which currently resides in
.rodata.str. Move it to .rodata.idmap to allow making use of print_reg
macro from anywhere (mostly to aid debugging).
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
On Arm32, after cleaning and invalidating the last dcache line of the top
domheap page i.e. VA = 0xfffff000 (as a result of flushing the page to
RAM), we end up adding the value of a dcache line size to the pointer
once again, which results in a pointer arithmetic overflow (with 64B line
size, operation 0xffffffc0 + 0x40 overflows to 0x0). Such behavior is
undefined and given the wide range of compiler versions we support, it is
difficult to determine what could happen in such scenario.
Modify clean_and_invalidate_dcache_va_range() as well as
clean_dcache_va_range() and invalidate_dcache_va_range() due to similarity
of handling to prevent pointer arithmetic overflow. Modify the loops to
use an additional variable to store the index of the next cacheline.
Add an assert to prevent passing a region that wraps around which is
illegal and would end up in a page fault anyway (region 0-2MB is
unmapped). Lastly, return early if size passed is 0.
Note that on Arm64, we don't have this problem given that the max VA
space we support is 48-bits.
This is XSA-447 / CVE-2023-46837.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
As a result of not checking the return code of device_tree_for_each_node()
in boot_fdt_info(), any error occured during early FDT parsing does not
stop Xen from booting. This can result in an unwanted behavior in later
boot stages. Fix it by checking the return code and panicing on an error.
Fixes: 9cf4a9a467 ("device tree: add device_tree_for_each_node()")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Introduce the CONFIG_UBSAN_FATAL option to cater to scenarios where prompt
attention to undefined behavior issues, notably during CI test runs, is
essential. When enabled, this option causes Xen to panic upon detecting
UBSAN failure (as the last step in ubsan_epilogue()).
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Move static event channel feature related code to a separate module
(static-evtchn.{c,h}) in the spirit of fine granular configuration, so
that the feature can be disabled if not needed.
Introduce Kconfig option CONFIG_STATIC_EVTCHN, enabled by default (to
keep the current behavior) dependent on CONFIG_DOM0LESS. While it could
be possible to create a loopback connection for dom0 only, this use case
does not really need this feature and all the docs and commit messages
refer explicitly to the use in dom0less system.
The only function visible externally is alloc_static_evtchn(), so move
the prototype to static-evtchn.h and provide a stub in case a feature
is disabled. Guard static_evtchn_created in struct dt_device_node as
well as its helpers.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Thanks to recent changes added to ImageBuilder to support the bootz
command, which allows obtaining the effective image size (including NOLOAD
sections) from the zImage header, switch the BOOT_CMD for arm32 tests to
bootz. Among other scenarios, this change will enable us, in the future,
to add tests with UBSAN enabled Xen, which would otherwise fail due to
incorrect image placement resulting in overlapping.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Macro print_reg is used to print a value of a register passed as an
argument. While today it is only used from within the common head.S,
in the future we might want to make use of it from other files, just
like PRINT(). It also serves as a great aid when debugging.
Expose print_reg macro by moving it to asm/arm64/macros.h and:
- rename putn to asm_putn to denote the usage from assembly only,
- use ENTRY() for asm_putn to make it globally visible.
This way the behavior will be consistent with what we already do on arm32.
Take the opportunity to get rid of unneeded stubs for early_puts,
init_uart and putn since the calls to them are already protected by
respective #ifdef CONFIG_EARLY_PRINTK.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Tested-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
At the moment, in order to use a different defconfig target than default,
one needs to specify KBUILD_DEFCONFIG=<target> on the command line.
Switch to weak assignment, so that it can be also obtained from
environment similar to other KCONFIG/KBUILD variables.
This change will activate the use of KBUILD_DEFCONFIG variable in CI
build jobs that so far would have had no effect if they didn't match the
default anyway.
Note, that we will deviate from Linux in this regard.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
[stefano: adjust commit message]
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
In __ubsan_handle_pointer_overflow(), fix the condition for determining
whether a pointer operation overflowed or underflowed. Currently, the
function reports "underflowed" when it should be reporting "overflowed"
and vice versa.
Example of incorrect error reporting:
void *foo = (void *)__UINTPTR_MAX__;
foo += 1;
UBSAN:
pointer operation underflowed ffffffff to 00000000
Fixes: 4e3fb2fb47 ("ubsan: add clang 5.0 support")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
At the moment, we do not check a return code from scan_pfdt_node()
called recursively. This means that any issue that may occur while
parsing and copying the passthrough nodes is hidden and Xen continues
to boot a domain despite errors. This may lead to incorrect device tree
generation and various guest issues (e.g. trap on attempt to access MMIO
not mapped in P2M). Fix it.
Fixes: 669ecdf8d6 ("xen/arm: copy dtb fragment to guest dtb")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
Generic timer dt node property "clock-frequency" (refer Linux dt binding
Documentation/devicetree/bindings/timer/arm,arch_timer.yaml) is used to
override the incorrect value set by firmware in CNTFRQ_EL0. If the value
of this property is 0 (i.e. by mistake), Xen would continue to work and
use the value from the sysreg instead. The logic is thus incorrect and
results in inconsistency when creating timer node for domUs:
- libxl domUs: clock_frequency member of struct xen_arch_domainconfig
is set to 0 and libxl ignores setting the "clock-frequency" property,
- dom0less domUs: "clock-frequency" property is taken from dt_host and
thus set to 0.
Property "clock-frequency" is used to override the value from sysreg,
so if it is also invalid, there is nothing we can do and we shall panic
to let user know about incorrect setting. Going even further, we operate
under assumption that the frequency must be at least 1KHz (i.e. cpu_khz
not 0) in order for Xen to boot. Therefore, introduce a new helper
validate_timer_frequency() to verify this assumption and use it to check
the frequency obtained either from dt property or from sysreg.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The list is out of date and does not specify all the hypercalls/sub-ops
we support, so update it.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
The x86 hypercall ABI really used to have 6-argument hypercalls. V4V, the
downstream predecessor to Argo did take 6th args.
However, the 6th arg being %ebp in the 32bit ABI makes it unusable in
practice, because that's the frame pointer in builds with frame pointers
enabled. Therefore Argo was altered to being a 5-arg hypercall when it was
upstreamed.
c/s 2f531c122e ("x86: limit number of hypercall parameters to 5") removed
the ability for hypercalls to take 6 arguments.
Update the documentation to match reality.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jason Andryuk <jandryuk@gmail.com>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
Skip the following Xen specific host device tree nodes/properties
from being included into hardware domain /chosen node:
- xen,static-heap: this property informs Xen about memory regions
reserved exclusively as static heap,
- xen,domain-shared-memory-v1: node with this compatible informs Xen
about static shared memory region for a domain. Xen exposes a different
node (under /reserved-memory with compatible "xen,shared-memory-v1") to
let domain know about the shared region,
- xen,evtchn-v1: node with this compatible informs Xen about static
event channel configuration for a domain. Xen does not expose
information about static event channels to domUs and dom0 case was
overlooked (by default nodes from host dt are copied to dom0 fdt unless
explicitly marked to be skipped), since the author's idea was not to
expose it (refer docs/misc/arm/device-tree/booting.txt, "Static Event
Channel"). Even if we wanted to expose the static event channel
information, the current node is in the wrong format (i.e. contains
phandle to domU node not visible by dom0). Lastly, this feature is
marked as tech-preview and there is no Linux dt binding in place.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Julien Grall <jgrall@amazon.com>
Michal Orzel