Under SVM, there are two copies of guest CR2. One is v->arch.hvm.guest_cr[2]
and one is in the VMCB.
Xen doesn't intercept CR2 accesses, so this mostly goes unnoticed; hardware
loads and saves the guest CR2 in the VMCB across VMRUN/VMExit.
For HAP guests (where #PF is not intercepted, and therefore we don't typically
inject #PF either), this causes the guest CR2 value to be lost on migrate. As
migration is cooperative and not done from the #PF handler, this also goes
unnoticed by guests.
It also means that an emulated MOV-from-CR2 reads a stale value.
Reported-by: Stefano Stabellini <sstabellini@kernel.org>
Fixes: d1bd157fbc ("Big merge the HVM full-virtualisation abstractions.")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Gitlab CI reported a crash on boot on Alder Lake hardware. The bug is years
old, making it an incredibly rare occurance:
(XEN) *** DOUBLE FAULT ***
(XEN) ----[ Xen-4.22-unstable x86_64 debug=y ubsan=y Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: e008:[<ffff82d04077bbc4>] arch/x86/setup.c#reinit_bsp_stack+0xfa/0x160
(XEN) RFLAGS: 0000000000010202 CONTEXT: hypervisor
(XEN) rax: 0000000000000007 rbx: ffff83049a4b0000 rcx: 00000000000006a2
(XEN) rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000
(XEN) rbp: ffff83049a4b7f00 rsp: ffff83049a4b7ef8 r8: ffff830497e47000
(XEN) r9: 00000000ffffffff r10: 00000000900c2121 r11: 000000009a392956
(XEN) r12: ffff830497e47000 r13: ffff830497e49f40 r14: 0000000000000000
(XEN) r15: ffff82d0407dad10 cr0: 0000000080050033 cr4: 0000000000f526e0
(XEN) cr3: 0000000043c16000 cr2: fffffffffffffffc
(XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
(XEN) Xen code around <ffff82d04077bbc4> (arch/x86/setup.c#reinit_bsp_stack+0xfa/0x160):
(XEN) 00 b9 a2 06 00 00 0f 30 <80> 3d 71 26 f1 ff 00 74 3e 48 8d 93 f8 5f 00 00
(XEN) Valid stack range: ffff83049a4b6000-ffff83049a4b8000, sp=ffff83049a4b7ef8, tss.rsp0=ffff83049a4b7fb0
(XEN) No stack overflow detected. Skipping stack trace.
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) DOUBLE FAULT -- system shutdown
(XEN) ****************************************
This is on the instruction boundary after enabling CET (writing MSR_S_CET) and
prior to establishing SSP. Despite identifying this as a critical window
where any fault was deadly (the CPU tries to push a shadow stack frame at 0,
hence the CR2 value wrapping around to the top of the address space), I
clearly forgot that this meant interrupts too, which are enabled.
Disable interrupts during the critical period.
Fixes: b60ab42db2 ("x86/shstk: Activate Supervisor Shadow Stacks")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
lr_mask doesn't have bits set beyond the hardware limit, with the upper bits
remaining zero. Therefore, for_each_set_bit() is a better option.
For ARM64, bloat-o-meter reports:
Function old new delta
vgic_sync_from_lrs 208 168 -40
but this doesn't highlight that it also removes a call to find_next_bit() from
each loop iteration.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <julien@xen.org>
The current use of long for total_avail_pages and outstanding_claims
creates an unnecessary mix of signed and unsigned types during page
allocation calculations. This necessitates awkward constructs
like '+ 0UL' to satisfy type matching in macros such as min().
Address this by normalizing `total_avail_pages` and `outstanding_claims`
from `long` to `unsigned long`.
As a direct consequence of making `total_avail_pages` unsigned, the
post-decrement assertions checking for `>= 0` are no longer logically
sound. Adjust those assertions to pre-decrement checks.
No functional change intended.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Bernhard Kaindl <bernhard.kaindl@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The setting of d->arch.hvm.params[] will uniformly happen at the bottom of
hvm_set_param(), hence as per Misra's classification redundantly doing so
earlier is "dead code".
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
The admin can control the upper bound wanted not only via command line
option, but also via XEN_SYSCTL_pm_op_set_max_cstate. While decisions how
to set up the system are okay this way as long as we deem the command line
option a strict upper bound, what to do during S3 resume should not be
based on that potentially varying value. Decisions there need to use
solely the strict upper bound we may have enforced ourselves (or which was
forced onto us via command line option).
Rather than altering pit_broadcast_is_available(), drop the function
altogether. It's pretty odd for acpi/cpu_idle.c to call into time.c, just
for that to call into acpi/cpu_idle.c again.
Fixes: 8d24303023 ("x86: don't write_tsc() non-zero values on CPUs updating only the lower 32 bits")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Only the setup_virtual_bridge_port() function was used. As such merge
that with _setup_bridge_port() and leave that as the remaining function.
The last user of setup_physical_bridge_port() was removed in 9fabe55939
("tools/hotplug: Remove network-*").
Signed-off-by: Elliott Mitchell <ehem+xen@m5p.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
Introduce an annotation similar to __hwdom_init and use it througout the
file. All external callers are either themselves __init or are limited to
OVERLAY_DTB=y. Adjust the Makefile accordingly to also have string
literals moved into .init.rodata.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
There's no need to call vfree() with the lock still held.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
SMCCC DEN0028G, section 3.1, states that for AArch64 SMC/HVC calls
using Wn, only the least significant 32 bits are significant and the
upper 32 bits must be ignored by the implementation.
So for SMC32 PSCI calls, Xen must not treat non-zero upper bits in the
argument registers as an error. Instead, they should be discarded when
decoding the arguments.
Arm ARM DDI 0487J.a (D1-5406) also notes that the upper 32 bits may be
implementation defined when entering from AArch32. Xen zeros them on
entry, but that guarantee is only relevant for 32-bit domains.
Update PSCI v0.2+ CPU_ON, CPU_SUSPEND, AFFINITY_INFO and SYSTEM_SUSPEND
to read SMC32 arguments via PSCI_ARG32(), while keeping the SMC64
handling unchanged.
No functional change is intended for PSCI 0.1.
Suggested-by: Julien Grall <julien@xen.org>
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
The GICv2 CPU shutdown path currently writes 0 to GICC_CTLR.
Per IHI0048B.b section 2.3.1, clearing the architected bypass-disable
bits selects bypass rather than deasserted interrupt outputs when the
CPU interface stops driving them. Tables 2-2 and 2-3 show that a zeroed
GICC_CTLR can fall back to the legacy IRQ/FIQ inputs instead of fully
disabling the interface.
Fix this by reading GICC_CTLR, then setting the bypass-disable bits and
clearing the group-enable bits that are architecturally defined for the
current GICC_CTLR view before writing the value back. When Security
Extensions are implemented Xen accesses the Non-secure copy of
GICC_CTLR, where IRQBypDisGrp1 and FIQBypDisGrp1 are at bits [6:5] and
bits [8:7] are reserved.
Without Security Extensions (GICD_CTLR.DS=1), GICD_IGROUPR is RAZ/WI
and all interrupts are Group 0, so clearing EnableGrp0 alone is
sufficient to stop interrupt delivery through the CPU interface.
Section 2.3.2 also states that wakeup event signals remain available
even when both GIC interrupt signaling and interrupt bypass are
disabled, so disabling bypass does not break the power-management use
case, i.e. suspend modes.
Fixes: 5e40a1b435 ("arm: SMP CPU shutdown")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Without --platform, it seems recent versions of docker ignores the
platform of the image when pushing, and it's pushed as the platform of
the runner.
If we happen to build an arm64 image on x86, with recent version of
docker, the image will be push as if it was an x86 image, then
`docker run --platform=linux/arm64 ...` fails. Even if it would
work without --platform, gitlab-runner will not be able to use the
image.
To go back to the previous behavior, we will extract --platform from
the dockerfiles, and use it on the command line.
--platform= is needed on both docker-build and docker-push. The first
one so that the image is tagged with the right platform, and the
second one so that we can push a "generic" image without been tagged
to a particular platform. --platform on docker-push allow to easly use
the container on any arch, without having to use --platform on
docker-pull or docker-run.
`docker push --platform` seem to have been added to 1.46, according to
the [doc], and doesn't exist on Podman. So we need to check that we
are using `docker` and that the API version is new enough.
[doc] https://docs.docker.com/reference/cli/docker/image/push/
Also, introduce the $img variable, to make the lines a bit shorter.
Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Uninitialized cpu_data[] entries have the apicid field set to BAD_APICID,
not boot_cpu_data.apicid. Fix the check in cpu_smpboot_free() to use the
correct condition.
Fixes: 7126b7f806 ("x86/CPU: re-work populating of cpu_data[]")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
There are two reasons of this change:
1. Align prototype with what other make_*_node() are passed.
2. A follow-up RISC-V patch will call get_next_free_phandle() inside
make_cpus_node(), requiring mutable access to kinfo->free_phandle.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
There are cases where it is necessary to know the next available phandle
number in order to generate phandles for guest device nodes.
When a partial FDT (pfdt) is provided, special care is needed during
initialization of next_phandle, as the pfdt may already contain a dummy
interrupt controller node with a phandle assigned to it. next_phandle
must therefore be initialized to one past the highest phandle already
present in the pfdt, to avoid collisions.
Since next_phandle may be needed for the very first guest node generated,
domain_handle_dtb_boot_module() is moved earlier in prepare_dtb_domU().
The new call site also aligns better with the existing comment stating
that domain_handle_dtb_boot_module() must be called before the rest of
the device tree is generated.
Introduce alloc_phandle() to ensure that phandles allocated for guest
nodes do not overlap the Xen-reserved phandle range. This helper will
be used by subsequent patches (by RISC-V at the moment).
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
overlay_get_nodes_info() is called before fdt_overlay_apply() to extract
target paths from the overlay. This fails for overlays using phandle-based
targeting (target = <&label>) because DTC compiles these as unresolved
fixups (target = <0xffffffff>), causing fdt_overlay_target_offset() to
return -FDT_ERR_BADPHANDLE. Prior to this change users were forced to
manually modify the dtbo (even for hwdom) to switch from target to
target-phandle by manually inspecting also the host DTB.
Introduce overlay_get_target_path() which directly handles the two
targeting cases that occur before fixup resolution:
- target-path: the string property is returned directly.
- target = <&label>: the label is found in the overlay's __fixups__
node, then resolved to a path via the base DTB's __symbols__ node.
Libfdt fdt_for_each_property_offset() violates MISRA R20.7. Despite
libfdt being excluded from the analysis, this causes ECLAIR scan to
report a regression because the violation introduced by a macro is
reported at the call site. Deviate R20.7 for libfdt.h.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
handle_attach_overlay_nodes() only calls handle_device() on the
top-level overlay nodes tracked in entry->nodes_address[]. Child nodes
that have their own reg, interrupts, or iommus properties are never
processed, so their IRQs are not routed, MMIO regions are not mapped,
and IOMMU setup is skipped.
Introduce handle_device_and_children() which recursively walks the
subtree rooted at each overlay node and calls handle_device() on every
descendant, ensuring all resources in the overlay are properly attached.
Note that the attach error path has a pre-existing bug: on partial
failure, the tracking rangesets are destroyed without first revoking the
IRQ/MMIO permissions and IOMMU assignments that were already granted by
the successful handle_device() calls. Add a TODO comment to flag this.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
dt_overlay_remove_node() silently returns 0 when the target node is not
found in the parent's sibling list. The loop simply exits without
matching and falls through to "return 0", making the caller believe the
node was successfully removed.
Return -ENODEV after the loop when no match is found, and change the
found-path from break to an explicit return 0 so the two outcomes are
distinct.
Fixes: 7e5c4a8b86 ("xen/arm: Implement device tree node removal functionalities")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
find_track_entry_from_tracker() compares overlay_fdt_size bytes of the
stored overlay against the input without verifying that the stored
overlay is at least that large. If the input is larger, memcmp reads
past the stored allocation. If smaller, a prefix match could falsely
succeed.
Compare fdt_totalsize() of the stored overlay against overlay_fdt_size
first. Both values are validated by check_overlay_fdt() at their
respective entry points, so no additional field in overlay_track is
needed.
Fixes: 7e5c4a8b86 ("xen/arm: Implement device tree node removal functionalities")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
handle_attach_overlay_nodes() unconditionally creates new rangesets
without checking whether they already exist from a prior attach. A
repeated attach for the same overlay leaks the original pair. Reject the
operation with -EEXIST if rangesets are already present.
Also, dt_overlay_domctl() early-returns -EOPNOTSUPP for any operation
other than ATTACH, making the if/else at the bottom unreachable. Remove
the dead branch.
Fixes: 4c733873b5 ("xen/arm: Add XEN_DOMCTL_dt_overlay and device attachment to domains")
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
handle_attach_overlay_nodes() destroys the IRQ and IOMEM rangesets on
failure but leaves the pointers dangling in the tracker entry. A
subsequent handle_remove_overlay_nodes() for the same overlay will call
rangeset_consume_ranges() on freed memory followed by a second
rangeset_destroy(), resulting in use-after-free and double-free.
NULL the pointers after rangeset_destroy() so that remove_nodes() and
handle_remove_overlay_nodes() skip the stale entries.
Fixes: 4c733873b5 ("xen/arm: Add XEN_DOMCTL_dt_overlay and device attachment to domains")
Reported-by: Gyujeong Jin <wlsrbwjd7232@gmail.com>
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
If a domain tries to map status frames in parallel to switching grant
table version from 2 to 1, the mapping operation may put in place P2M
entries referencing MFNs which gnttab_unpopulate_status_frames() is in the
process of freeing.
Ideally we would refcount pages when entered into P2M tables, but that's a
significant change. Extend the grant-table-locked region instead in
xenmem_add_to_physmap_one() (being the sole caller of gnttab_map_frame()),
such that a race with gnttab_unpopulate_status_frames() is no longer
possible.
This is XSA-486 / CVE-2026-23558.
Fixes: 5ce8fafa94 ("Dynamic grant-table sizing")
Fixes: a98dc13703 ("Introduce a grant_entry_v2 structure")
Reported-by: Rafal Wojtczuk <rafal.wojtczuk@7bulls.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
conn_delete_all_transactions() should be callable in any context,
resetting ALL transaction related data.
This includes number of active transactions and the transaction
pointer in struct connection.
So reset conn->trans to NULL in conn_delete_all_transactions() and
do the cleanup for each transaction in destroy_transaction().
This avoids triggering the assert() in conn_delete_all_transactions()
in case e.g. ignore_connection() was called while an operation inside
a transaction was performed, or XS_RESET_WATCHES was called in a
transaction.
This is XSA-484 / CVE-2026-23557.
Reported-by: Andrii Sultanov <andriy.sultanov@vates.tech>
Fixes: 1f9d04fb02 ("xenstored: allow guest to shutdown all its watches/transactions")
Signed-off-by: Juergen Gross <jgross@suse.com>
The quota object contains both limits and the current node usage counts.
When a domain is torn down, the node data itself is cleaned up but the node
usage counts are not. A later domain reusing the same domid can create fewer
nodes before being deemed to be over quota.
Reset the count when the node permissions are cleaned up.
This is XSA-483 / CVE-2026-23556.
Signed-off-by: Andrii Sultanov <andriy.sultanov@vates.tech>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
GITS_BASER_INNER_CACHEABILITY_MASK and
GICR_PROPBASER_INNER_CACHEABILITY_MASK are shifted masks. Comparing the
masked but unshifted values against GIC_BASER_CACHE_nC, which is an
unshifted enum value, leads to incorrect detection of non-cacheable
GITS_BASER tables and GICR_PROPBASER mappings.
Use MASK_EXTR() to decode these cacheability fields before comparing
against GIC_BASER_CACHE_nC, so the backing memory is flushed when
required.
Fixes: 05238012b8 ("ARM: GICv3 ITS: allocate device and collection table")
Fixes: c9b939863c ("ARM: GICv3: allocate LPI pending and property table")
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
When LLC coloring is enabled, the hardware domain gets memory from
host free regions rather than the fixed guest RAM banks. The previous
code sorted these regions by descending size, which usually causes
high-address memory to be allocated first.
All allocated memory could reside above 4 GB leaving DMA non-functional
for devices with limited addressing capabilities.
Improve the handling as follows:
- Sort free regions by ascending address instead of descending size,
so low-memory banks are allocated first,
- Skip banks smaller than 128 MB (or the total remaining allocation,
whichever is less) until the first bank is placed, ensuring
place_modules() has enough contiguous space,
- Extract the hardware domain allocation path into its own function
(allocate_hwdom_memory) for clarity.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
In exynos4210_uart_init_postirq(), when setup_irq() returns an error
the failure was only logged via dprintk() and execution continued,
unconditionally clearing UINTM and setting UMCON_INT_EN. This enabled
receive and transmit interrupt lines with no handler registered. On
platforms where the GIC receives these asserted lines, the result is
either repeated spurious-interrupt warnings or an unhandled interrupt
fault.
Add an early return in the setup_irq() error branch so that the
interrupt-enable writes to UINTM and UMCON are skipped when IRQ
registration fails.
Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
In cuart_init_postirq(), two code paths could reach the
interrupt-enable write to IER without a handler being registered:
- When no valid IRQ number was provided (uart->irq <= 0), the original
positive-condition guard (if uart->irq > 0) skipped the irqaction
setup but still fell through to the IER write, enabling the receive
data interrupt with no handler installed.
- When setup_irq() returned an error, only an error message was
printed and execution continued to the IER write, arming the
receive hardware interrupt line with no handler to service it. On
platforms where the GIC receives this asserted line, the result is
either repeated spurious-interrupt warnings or an unhandled
interrupt fault.
Restructure cuart_init_postirq() to use early returns in both error
paths.
Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
In pl011_init_postirq(), two code paths could reach the
interrupt-unmask write to IMSC without a handler being registered:
- When no valid IRQ number was provided (uart->irq <= 0), the original
positive-condition guard (if uart->irq > 0) skipped the irqaction
setup but still fell through to the IMSC write, unmasking
RTI|OEI|BEI|PEI|FEI|TXI|RXI with no handler installed.
- When setup_irq() returned an error, only an error message was
printed and execution continued to the IMSC write, arming all
hardware interrupt lines with no handler to service them. On
platforms where the GIC receives these asserted lines, the result
is either repeated spurious-interrupt warnings or an unhandled
interrupt fault.
Restructure pl011_init_postirq() to use early returns: return
immediately when no valid IRQ is provided, and return after logging
the error when setup_irq() fails. The interrupt-enable write to IMSC
is only reached when IRQ registration succeeds.
Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
In scif_uart_init_postirq(), when setup_irq() returns an error the
failure was only logged via dprintk() and execution continued,
unconditionally writing TIE|RIE|REIE into the Serial Control Register
(SCSCR). This armed all three hardware interrupt lines (TX FIFO empty,
RX data ready, receive error) with no handler registered to service
them. On platforms where the GIC receives these asserted lines, the
result is either repeated spurious-interrupt warnings or an unhandled
interrupt fault.
The fix adds an early return inside the error branch. The
interrupt-enable write to SCSCR is skipped entirely when no handler is
registered.
SCIF TX continues to operate correctly after this change. The Xen
serial framework never calls serial_async_transmit() for SCIF, so
port->txbuf is always NULL. This causes __serial_putc() to take the
synchronous finite-capacity path, which polls the SCFSR_TDFE hardware
flag directly and does not depend on the interrupt mechanism. RX
wouldn't work if irq wasn't registered.
As a secondary clean-up, the hardware error-flag clearing sequence is
moved to before the setup_irq() call so that error bits accumulated
since init_preirq() are cleared unconditionally, regardless of whether
IRQ registration succeeds.
Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
When the variable is set, only build jobs that are used in tests are
scheduled. This saves a lot of time, for example when scheduling a test
pipeline with alternative linux branch.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Allow choosing which artifacts branch and job to use for Linux. This
allows running the same tests for different Linux versions, without
duplicating a lot of yaml sections.
Similarly, make the repo path itself configurable too. The main purpose
is to ensure the test pipeline triggered from any repo will fetch linux
artifact from the right repo. But with a minor change of using that
variable for rootfs and microcode artifacts too, it allows testing
test-artifacts repo changes without needing to modify gitlab-ci.yml in
xen.git at all.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
create_node() is called only for issued xenstore commands. This means
that the "conn" parameter is never NULL.
Remove checking whether "conn" is not NULL.
Coverity ID: 1690859
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
In various distros (i.e. Debian), /lib is a symbolic link. The tar
command in install.sh replaces the /lib symlink with a directory and
results in a non-functioning system. This has been introduced by the
installation of the systemd watchdog sleep script in /lib/systemd.
This patch adds the tar option --dereference (-h for short) to preserve
symlinks when extracting the dist archive.
Fixes: e54a6cd6a1 ("systemd: Add hooks to stop/start xen-watchdog on suspend/resume")
Signed-off-by: Thierry Escande <thierry.escande@vates.tech>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Tested-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
Clang 22.x.x or Arm Toolchain for Embedded 22.x.x reports:
In file included from arch/arm/tee/ffa.c:75:
arch/arm/tee/ffa_private.h:439:17: error: 'used' attribute ignored on a non-definition declaration [-Werror,-Wignored-attributes]
439 | extern uint32_t __ro_after_init ffa_fw_version;
| ^
There is a fix for clang 16 in the git history:
a1a1e2b7dc ("xen/arm: ffa: fix build with clang")
which was broken by the following commit:
a90376c6ad ("xen/arm: ffa: Add FF-A 1.2 endpoint memory access descriptors")
Remove __ro_after_init from the extern declaration of ffa_fw_version.
The attribute is already present on the definition in ffa.c, which is
sufficient and correct.
Fixes: a90376c6ad ("xen/arm: ffa: Add FF-A 1.2 endpoint memory access descriptors")
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Branch offset decoding sign-extends the immediate by shifting it left into
bit 31 and back. Perform the left shift in uint32_t and cast to int32_t
only for the final right shift to avoid UBSAN failures on negative offsets.
Fixes: 6dbf3f0e30 ("xen/arm: arm64: Add helpers to decode and encode branch instructions")
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
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>
ENODATA is not defined on FreeBSD:
xenpm.c:1380:17: error: use of undeclared identifier 'ENODATA'
1380 | errno = ENODATA;
| ^
1 error generated.
Fixes: edb657887a ("xenpm: Add get-core-temp subcommand")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
L1 present entries that require the underlying page to be freed have the
_PAGE_AVAIL0 bit set, introduce a helper to unify the checking logic into a
single place.
No functional change intended.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
OpenSBI currently does not advertise the SSTC extension via the device
tree, so if SSTC support is detected by Xen the riscv_isa bitmap is updated
manually. Furthermore, removing the "sstc" string from riscv,isa is not
a reliable way to disable SSTC, because OpenSBI probes support by
attempting to access CSR_STIMECMP.
Introduce a runtime probe in Xen to determine whether SSTC is available.
The probe attempts to read CSR_STIMECMP using csr_read_safe(). If the
access succeeds, SSTC is considered available; if a trap occurs, it is
treated as unsupported.
When SSTC is detected, Xen may use it internally to program timers.
However, the extension is not exposed to guests because the required
context switch handling for the SSTC CSRs is not yet implemented.
Note: clearing RISCV_ISA_EXT_sstc from the DTS riscv,isa property is
deferred to a follow-up patch. Also, the corresponding HENVCFG bit is
not set so guests fall back to the SBI timer interface. Timer requests
are then handled by Xen via the usual SBI interception path.
Introduce set_xen_timer() to abstract how the timer is programmed,
either via the SSTC extension or an SBI call.
Drop sbi_set_timer() as it is more than enough to have only introduced
set_xen_timer().
Drop "SBI v0.2 TIME extension detected" message to avoid confusion
which set timer function is really used.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Avoid open-coding macros we have readily available. Being able to use MB()
there might have avoided the flaw corrected by 5416c455f6 ("x86/mkelf32:
Actually pad load segment to 2 MiB boundary").
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Allow them to be used by build tools which don't include config.h. (They
also don't really fit into config.h, as there's nothing "configuration"
related about them.)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Add a "-d <depth>" parameter to xenstore-watch, allowing to specify
the depth parameter of the XS_WATCH command.
Using "-d" without support of depth by xenstored will refuse to set
the watch(es).
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Add XENSTORE_SERVER_FEATURE_WATCHDEPTH to the available features now
that all needed support has been added.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
With XENSTORE_SERVER_FEATURE_WATCHDEPTH available, special watch
handling needs to be extended:
- when a special watch is set with depth = 1, the domid is added to
the watch event
- it is possible to watch for @releaseDomain/<domid>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Today fire_watches() has the boolean "exact" parameter specifying how
the matching of the modified node with registered watches is to be
handled (only the exact node name is matching or all nodes being
in the subtree beneath the watched node).
For the handling of <special-watch>/<domid> watch events 2 additional
matching possibility needs to be added, as those events should only
be delivered to clients having requested such events, either by
watching <special-watch> with the depth=1 parameter, or by directly
watching for <special-watch>/<domid>, while the traditional special
watch events should NOT delivered to those watchers.
For this purpose rename the "exact" parameter to "match" and make it
an enum with four possible values.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Andrew Cooper