decode_fsc() derives the fault level from the low two bits of the FSC, so
level 0 is a valid output: FSC_FLT_TRANS is 0x04, i.e. "translation fault,
level 0 or translation table base register".
This is reachable on arm64 because xen_pgtable is the zeroeth-level root,
but fsc_level_str() has no case for it and prints " (level invalid)"
instead. At the time the function was created Xen used only three levels.
Add the missing case. On arm32 the zeroeth level does not exist but FSC
0 denotes address size fault at translation table base register.
While at it, make decode_fsc() decode also address size faults.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
(cherry picked from commit 4e1f58ea1a)
The comments on the PMINTENSET/PMINTENCLR cases claim that an EL0 access
may be trapped to EL2 when MDCR_EL2.TPM is set, and that such a case is
handled. Both are inaccurate. PMINTENSET_EL1/PMINTENCLR_EL1 are accessible
at EL1 and above only, with no enable making them accessible at EL0.
Arm ARM (DDI 0487M.b) D1.4.5.6 "Prioritization of Synchronous
exceptions" orders the two exceptions. An access that is never
accessible at the current Exception level regardless of any enables or
traps is priority 18, whereas an exception taken to EL2 as the result of
a configuration control in MDCR_EL2 is priority 24. An EL0 access is
therefore UNDEFINED and taken to EL1.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
(cherry picked from commit 87a8a5728e)
process_domain_node() parses "xen,static-mem" regardless of
CONFIG_STATIC_MEMORY. With the feature off, init_staticmem_pages() is a
no-op stub, so boot carries on until construct_domU() reaches the
ASSERT_UNREACHABLE() stubs of allocate_static_memory() /
assign_static_memory_11(): a debug build trips the assertion, a production
build gives the domain no memory at all.
Bail out at parse time instead, like process_shm_node() already does for
CONFIG_STATIC_SHM.
Fixes: 41c031ff43 ("xen/arm: introduce domain on Static Allocation")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>
(cherry picked from commit e888192d13)
construct_domain() creates the secondary vCPUs in a loop, but on a
vcpu_create() failure it only prints a message and breaks out of the
loop returning success. As a result the domain can be partially
constructed with fewer vCPUs than d->max_vcpus. This causes two contract
violations:
- Xen-Guest: domain's FDT is generated before vCPU creation - Xen exposes
incorrect information (e.g. two vCPUs listed in a device tree while only
one is actually created),
- User-Xen: unlike x86, on Arm port we try to bail out as soon as
possible on unsatisfied user requests (e.g. user requested two vCPUs
for a domain but it was created with only one).
Return an error instead of breaking out of the loop. Both callers
(construct_domU() and construct_hwdom()) already propagate a negative
return value and fail domain construction.
Fixes: 6b0e8e4334 ("xen/arm: allocate secondaries dom0 vcpus")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
(cherry picked from commit e3aa330017)
On Arm we stay on the safe side and refuse to create a domain on user
requests (e.g. via xl.cfg, DT options) that cannot be satisfied due to
the feature not being compiled in. SCI fall through the crack and does not
adhere to that i.e. a user request for SCI type other than NONE when
CONFIG_SCMI_SMC (and thus CONFIG_ARM_SCI) is not set would be silently
ignored. Fix it by not allowing anything else other than NONE if the
feature is not enabled.
Fixes: 10e7473d60 ("xen/arm: scmi-smc: passthrough SCMI SMC to domain, single agent")
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>
(cherry picked from commit f7b9752dc8)
gicv3_iomem_deny_access() incorrectly uses csize (physical CPU
interface size) instead of vsize (virtual CPU interface size) when
calculating the number of pages to deny for the virtual CPU interface
region at vbase.
Fixes: 8300b3377e ("arm/gic: Add a new callback to deny Dom0 access to GIC regions")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
(cherry picked from commit 9af54b65a4)
iomem_deny_access() wraps rangeset_remove_range() which takes inclusive
endpoints. All call sites in the GIC and ACPI code pass 'mfn + nr' (or
'mfn + 1' for single-page regions) as the end parameter, which causes
one extra page beyond each region to be denied.
For single-page regions, use 'mfn' as the end (denying exactly one page).
For all multi-page regions, use 'mfn + nr - 1'.
This matches the correct pattern used elsewhere, e.g. in device.c.
Fixes: 8300b3377e ("arm/gic: Add a new callback to deny Dom0 access to GIC regions")
Fixes: 66158be465 ("ARM: ITS: Deny hardware domain access to ITS")
Fixes: 97e9875646 ("arm/acpi: Permit MMIO access of Xen unused devices for Dom0")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@amd.com>
(cherry picked from commit f25fe2452b)
A number of CPUs developed by Arm suffer from errata whereby a broadcast
TLBI + DSB sequence may complete before the global observation of writes
which are translated by an affected TLB entry. This can lead to memory
corruption and potential privilege escalation.
These errata ONLY affect the completion of memory accesses which have
been translated by an invalidated TLB entry, and these errata DO NOT
affect the actual invalidation of TLB entries. TLB entries are removed
correctly.
To mitigate this issue, Arm recommends that software follows each
TLBI+DSB sequence with an additional TLBI+DSB, which will ensure that
all memory write effects affected by the first TLBI have been globally
observed.
The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the
issue. Enable this workaround for affected CPUs.
This is XSA-493 / CVE-2025-10263.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Julien Grall <julien@xen.org>
(cherry picked from commit 161e8f61b5)
Add processor definitions for C1-Premium. These will be used for errata
detection in subsequent patches.
These values can be found in the C1-Premium TRM:
https://developer.arm.com/documentation/109416/0100/
... in section A.5.1 ("MIDR_EL1, Main ID Register").
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Julien Grall <julien@xen.org>
(cherry picked from commit 0315d10321)
Add processor definitions for C1-Ultra. These will be used for errata
detection in subsequent patches.
These values can be found in the C1-Ultra TRM:
https://developer.arm.com/documentation/108014/0100/
... in section A.5.1 ("MIDR_EL1, Main ID Register").
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Julien Grall <julien@xen.org>
(cherry picked from commit 36ddaa7918)
Synchronize with Linux kernel 7.0 definitions for the following CPUs:
- Cortex-A76AE,
- Cortex-A78AE,
- Cortex-X1C,
- Cortex-X3,
- Neoverse-V2,
- Cortex-X4,
- Neoverse-V3AE,
- Neoverse-V3,
- Cortex-X925.
These will be used for errata detection in subsequent patches.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Julien Grall <julien@xen.org>
(cherry picked from commit d54682a5b2)
The ARM64_WORKAROUND_REPEAT_TLBI workaround is used to mitigate several
errata where broadcast TLBI;DSB sequences don't provide all the
architecturally required synchronization. The workaround performs more
work than necessary, and can have significant overhead. This patch
optimizes the workaround, as explained below.
1. All relevant errata only affect the ordering and/or completion of
memory accesses which have been translated by an invalidated TLB
entry. The actual invalidation of TLB entries is unaffected.
2. The existing workaround is applied to both broadcast and local TLB
invalidation, whereas for all relevant errata it is only necessary to
apply a workaround for broadcast invalidation.
3. The existing workaround replaces every TLBI with a TLBI;DSB;TLBI
sequence, whereas for all relevant errata it is only necessary to
execute a single additional TLBI;DSB sequence after any number of
TLBIs are completed by a DSB.
For example, for a sequence of batched TLBIs:
TLBI <op1>[, <arg1>]
TLBI <op2>[, <arg2>]
TLBI <op3>[, <arg3>]
DSB ISH
... the existing workaround will expand this to:
TLBI <op1>[, <arg1>]
DSB ISH // additional
TLBI <op1>[, <arg1>] // additional
TLBI <op2>[, <arg2>]
DSB ISH // additional
TLBI <op2>[, <arg2>] // additional
TLBI <op3>[, <arg3>]
DSB ISH // additional
TLBI <op3>[, <arg3>] // additional
DSB ISH
... whereas it is sufficient to have:
TLBI <op1>[, <arg1>]
TLBI <op2>[, <arg2>]
TLBI <op3>[, <arg3>]
DSB ISH
TLBI <opX>[, <argX>] // additional
DSB ISH // additional
Using a single additional TLBI and DSB at the end of the sequence can
have significantly lower overhead as each DSB which completes a TLBI
must synchronize with other PEs in the system, with potential
performance effects both locally and system-wide.
4. The existing workaround repeats each specific TLBI operation, whereas
for all relevant errata it is sufficient for the additional TLBI to
use *any* operation which will be broadcast, regardless of which
translation regime or stage of translation the operation applies to.
For example, for a single TLBI:
TLBI ALLE2IS
DSB ISH
... the existing workaround will expand this to:
TLBI ALLE2IS
DSB ISH
TLBI ALLE2IS // additional
DSB ISH // additional
... whereas it is sufficient to have:
TLBI ALLE2IS
DSB ISH
TLBI VALE1IS, XZR // additional
DSB ISH // additional
As the additional TLBI doesn't have to match a specific earlier TLBI,
the additional TLBI can be implemented in separate code, with no
memory of the earlier TLBIs. The additional TLBI can also use a
cheaper TLBI operation.
5. The existing workaround is applied to both Stage-1 and Stage-2 TLB
invalidation, whereas for all relevant errata it is only necessary to
apply a workaround for Stage-1 invalidation.
Architecturally, TLBI operations which invalidate only Stage-2
information (e.g. IPAS2E1IS) are not required to invalidate TLB
entries which combine information from Stage-1 and Stage-2
translation table entries, and consequently may not complete memory
accesses translated by those combined entries. In these cases,
completion of memory accesses is only guaranteed after subsequent
invalidation of Stage-1 information (e.g. VMALLE1IS).
Rework the workaround logic as follows:
- add TLB_HELPER_LOCAL() to be used for local TLB ops without a
workaround,
- modify TLB_HELPER() workaround to use tlbi vale2is, xzr as a second
TLBI,
- drop TLB_HELPER_VA(). It's used only by __flush_xen_tlb_one_local
which is local and does not need workaround and by
__flush_xen_tlb_one. In the latter case, since it's used in a loop,
we don't need a workaround in the middle. Add __tlb_repeat_sync with
a workaround to be used at the end after DSB and before final ISB,
- TLBI VALE2IS passing XZR is used as an additional TLBI. While there is
an identity mapping there, it's used very rarely. The performance
impact is therefore negligible. If things change in the future, we
can revisit the decision.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
(cherry picked from commit 7c502d7591)
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>
Michal Orzel