The DT dma-noncoherent property describes the bus coherency of the
device represented by the node. On an ITS subnode, that is memory
accessed by that ITS. Add GICV3_QUIRK_MEM_NC_NS to the corresponding
host_its and use it when programming GITS_CBASER and GITS_BASER<n>.
On the top-level GIC node, the property describes the Redistributor side
of the LPI path. Collect it in gicv3_lpi_init_host_lpis() and apply it
only to the host LPI policy used when allocating the property and
pending tables and when programming GICR_PROPBASER and GICR_PENDBASER.
Mark the function init-only because firmware attributes are collected
only during boot.
Do not inherit the property between parent and child nodes: ITS-node
non-coherency does not change the global host LPI policy, and GIC-node
non-coherency does not change per-ITS quirk_flags.
ACPI is unchanged; this patch only consumes the DT dma-noncoherent
property.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
ITS quirks are matched only by IIDR and mask fields stored in each table
entry. That is too coarse when the same GIC IP block appears on several
platforms but a workaround is valid only for some of them.
Replace the fixed IIDR fields with a generic match(hw_its, data)
callback and an opaque data pointer. Add an IIDR matcher as a reusable
building block and use it from the R-Car Gen4 matcher after checking the
Renesas machine compatibles.
This intentionally narrows the R-Car Gen4 quirk. Previously every ITS
with IIDR 0x0201743b matched. Now it matches only a DT-discovered ITS on
an r8a779f0 or r8a779g0 machine. ACPI-discovered ITSes and the same IIDR
on other platforms no longer match.
Keep first-match semantics explicit. Use BUG_ON() if a non-sentinel
entry has no matcher or the IIDR matcher receives no data. A broken
entry must stop Xen in both debug and release builds, as skipping a
required workaround could cause a failure later. Place the matcher data
and table in init-only read-only sections.
The matched entry still supplies separate ITS and LPI flags; this patch
only changes how the entry is selected.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
ITS quirks can impose restrictions on memory accessed by the ITS itself
and on shared host LPI/Redistributor state. These scopes are not
identical, so a single global ITS quirk state makes the host LPI policy
depend implicitly on the quirks seen while initializing host ITSes.
Add per-ITS quirk_flags to struct host_its and keep a separate
host_lpi_flags state in the LPI code. The quirk table now records the
ITS-private and host LPI scopes explicitly through its_flags and
lpi_flags. The R-Car Gen4 quirk applies the same memory restrictions to
both scopes, preserving the existing R-Car memory policy without relying
on an implicit aggregation step.
This also removes the assumption that all host ITSes must expose the
same quirk state. ITS-derived host LPI restrictions are accumulated only
from quirk entries that explicitly set lpi_flags.
Use per-ITS quirk_flags for GITS_CBASER, GITS_BASER<n>, and ITT
allocations. Use host_lpi_flags when allocating the property and pending
tables and when programming GICR_PROPBASER and GICR_PENDBASER.
Memory-related quirk bits are named GICV3_QUIRK_MEM_* and are translated
by shared gicv3_mem_get_*() helpers.
Collect both scopes during the ITS preparation pass, before host LPI
state is allocated. Keep init-only annotations and includes in the
implementation files rather than the public header.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
The boot CPU pending table must use the memory attributes selected by
ITS quirks. gicv3_lpi_init_host_lpis() is therefore called after
gicv3_its_init(). However, gicv3_its_init() also programs and enables
each ITS before host LPI state is allocated. No ITS commands are
submitted at that point, but this ordering relies on that implementation
detail.
Split per-ITS initialization into preparation and activation phases.
First map and disable every ITS and collect its quirks. Then initialize
host LPI state. Only after that, allocate and program the ITS tables and
command queue, and enable each ITS.
The subsequent gicv3_cpu_init() sequence remains unchanged: it programs
the Redistributor LPI tables, enables LPIs, and then submits the first
MAPC and SYNC commands.
Drop the now unreachable stub for gicv3_lpi_init_host_lpis().
Suggested-by: Julien Grall <julien@xen.org>
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Xen exposes ID_AA64PFR0_EL1.GIC and ID_PFR1.GIC from domain_cpuinfo,
which is initialized from the sanitized host CPU feature state. This
does not necessarily match the virtual interrupt controller configured
for a domain.
A vGICv2 domain can therefore observe a nonzero GIC field when the host
supports the GIC system register interface, even though Xen disables that
interface for the domain. On a GICv4.1-capable host, a vGICv3 domain can
observe encoding 0b0011, although Xen exposes only its vGICv3 model.
Derive the fields from the domain's vGIC version instead. Expose 0b0000
for vGICv2 and 0b0001 for vGICv3. This covers ID_AA64PFR0_EL1 and the
ID_PFR1_EL1 alias in AArch64 state, as well as ID_PFR1 accessed through
CP15 in AArch32 state. Leave the alias unchanged when AArch32 is
unavailable.
Fixes: 07b9acea11 ("xen/arm: Add handler for ID registers on arm64")
Fixes: 8f81064a07 ("xen/arm: Add handler for cp15 ID registers")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
The allocated_irqs bitmap in the existing vGIC implementation stores eSPI
allocation bits immediately after the regular vIRQ bits.
vgic_reserve_virq() converts an eSPI INTID to this compressed bitmap index,
but vgic_free_virq() used the raw INTID.
Freeing INTID 4096 therefore clears bit 4096 instead of the first eSPI bit.
This writes beyond allocated_irqs and leaves the intended eSPI bit set.
Valid eSPIs reach this path during DOMCTL bind failure cleanup and unbind,
and during vPL011 teardown.
Add virq_to_idx(), the inverse of idx_to_virq(), and use it when reserving
and freeing vIRQs. Use vgic_is_valid_line() for the validity checks when
reserving and freeing vIRQs in both vGIC implementations.
Fixes: bdde400c6e ("xen/arm: vgic: add resource management for extended SPIs")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
GICv3 eSPI support makes nr_irqs span the architectural INTID namespace
through ESPI_MAX_INTID, but descriptor storage is sparse. local_irq_desc[]
and irq_desc[] cover INTIDs below NR_IRQS, while espi_desc[] covers eSPIs.
INTIDs 1024 through 4095 have no backing descriptors.
Validation based only on nr_irqs accepts an INTID in this gap.
__irq_to_desc() then indexes beyond irq_desc[], and callers may lock or
update unrelated Xen memory.
Reject INTIDs that the GIC reports as unimplemented in setup_irq() before
looking up a descriptor. irq_set_spi_type() can run before the implemented
GIC line counts are available, so validate descriptor-backed ranges there
before looking up a descriptor.
Use the same descriptor range check in irq_set_spi_type() and the
assertion in __irq_to_desc() to keep them in sync. Log the IRQ number
when setup_irq() rejects an invalid line.
Fixes: 98f7060b9e ("xen/arm/irq: add handling for IRQs in the eSPI range")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
is_espi() currently changes its result according to CONFIG_GICV3_ESPI.
Without eSPI support, it returns false, and its assertion fails if
an eSPI INTID is passed. Callers therefore use it both to identify
eSPIs and to exclude eSPI handling when support is disabled.
Make is_espi() report only whether an INTID is in the architectural
eSPI range. Check for eSPI support at the call sites.
Use BUG_ON() if the GIC reports an eSPI without compiled-in support,
matching the handling of unsupported LPIs. Treat virtual eSPI lookup
without support as unreachable, with a NULL return from the
espi_to_pending() stub.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Several Arm firmware initialization paths discard irq_set_type()'s return
value, violating MISRA C Rule 17.7. If trigger configuration fails,
initialization continues with an IRQ that was not configured as requested.
GTDT and MADT retain rejected timer and maintenance INTIDs.
check_timer_irq_cfg() and release_irq() later perform unconditional
descriptor lookups on those values. Xen has no backing descriptors for
INTIDs 1024 through 4095, so retaining one can cause an out-of-bounds
access.
Check the return value in the GTDT, MADT, SPCR, and FF-A paths. Store timer
INTIDs only after successful trigger configuration, make GTDT parsing
failure fatal, and stop notification setup when trigger configuration
fails. Keep the NS16550 and PL011 consoles available by falling back to
polling, with a warning, if their IRQ trigger configuration fails.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
The GICv3 secondary_init() callback can fail while discovering or
waking a Redistributor, enabling LPIs, or setting up an ITS collection.
gic_init_secondary_cpu() currently discards that status. start_secondary()
then marks the CPU online even though its per-CPU GIC interface may be
unusable.
Return the callback status through the common GIC layer. Have
start_secondary() report the failure and stop the affected CPU before it
updates system features or is added to cpu_online_map.
Fixes: bc183a0235 ("xen/arm: Add support for GIC v3")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
PSR_GUEST64_INIT currently masks SError, IRQ and FIQ, but leaves debug
exceptions unmasked. Both the AArch64 Linux boot protocol and PSCI entry
requirements expect PSTATE.DAIF to be masked.
Add PSR_DBG_MASK to PSR_GUEST64_INIT. This fixes the initial AArch64 guest
entry state as well as virtual PSCI CPU_ON and SYSTEM_SUSPEND resume entry.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Julien Grall <julien@xen.org>
The shutdown flow currently uses is_shutting_down and is_shut_down to
represent the domain shutdown lifecycle. The two flags are not mutually
exclusive: after shutdown completion is_shutting_down remains set until
domain_resume() clears both flags.
Replace the two booleans with an enum domain_shutdown_state. Keep
domain_shutting_down() as the direct replacement for the old
is_shutting_down flag: it is true once shutdown has been initiated and
remains true after completion, until domain_resume(). Add
domain_shutdown_completed() for users that need the final completed
state.
This makes the state transition explicit while avoiding a semantic split
between "in progress" and "completed" at call sites where the old code
only cared that shutdown had started and had not yet been reset by
domain_resume().
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Juergen Gross <jgross@suse.com>
gicv3_lpi_init_host_lpis() initializes Xen-side host LPI bookkeeping,
registers the CPU notifier, and allocates the boot CPU pending table.
The pending table allocation uses gicv3_its_get_memflags().
ITS quirks are discovered by gicv3_its_init(), so allocating the boot
CPU pending table from gicv3_dist_init() can happen before the memory
restrictions required by the ITS are known. On affected systems this
can leave the pending table allocated using the default memory policy.
Move host LPI initialization after gicv3_its_init(), and only run it
when a host ITS was found. The old call ignored the return value. Now
that the call is made from gicv3_init(), check it and panic on failure
because Redistributor LPI initialization relies on that state being
available.
Although this reorders host LPI bookkeeping with respect to ITS
initialization, it does not change the hardware-visible LPI setup
sequence. gicv3_lpi_init_host_lpis() does not program the
Redistributor or submit any ITS commands. gicv3_cpu_init() still
programs GICR_PENDBASER/GICR_PROPBASER via
gicv3_lpi_init_rdist(), sets GICR_CTLR.EnableLPIs, and only then calls
gicv3_its_setup_collection(), which submits the first MAPC/SYNC
commands. Therefore, the ordering introduced by 95604873cc remains
unchanged.
This also narrows the condition for host LPI initialization from
"GICD advertises LPIs" to "a host ITS was discovered". This is
intentional: Xen currently has no supported LPI path without a host
ITS, and gicv3_lpi_init_rdist() already rejects that case with
-ENODEV. Therefore, on systems where GICD_TYPE_LPIS is set but no host
ITS is present, skipping gicv3_lpi_init_host_lpis() only avoids
allocating host LPI state that cannot be used by a supported Xen LPI
path.
Fixes: dcb6cb2636 ("ARM: GICv3 ITS: introduce host LPI array")
Fixes: 751ec850ec ("ARM: ITS: implement quirks and add support for Renesas Gen4 ITS")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
With LLC coloring enabled, the hardware domain memory is allocated by
allocate_hwdom_memory() rather than by using the fixed direct-map layout.
Commit de99f32635 ("device-tree: Improve hwdom memory allocation for
DMA") made that allocator prefer lower host regions. The first-bank
filter, however, still only checked the old 128MB heuristic. A low region
can satisfy that heuristic but still be too small, or otherwise
unsuitable, for the hardware-domain kernel and the DTB/initrd area to fit
in bank 0 according to the Arm placement rules.
Keep the existing first-bank size policy and add an architecture-specific
candidate check. On Arm, compute the kernel load address for the
candidate bank using the same logic as kernel_zimage_place(), verify that
the kernel range is covered by that bank, and then reuse the same
DTB/initrd placement helper as place_dtb_initrd(). The FDT is generated
later, so use the hardware-domain FDT allocation size as a conservative
upper bound for the final DTB size.
Check the candidate after capping the host region by the remaining
unassigned hardware-domain memory, so the validation is performed against
the size that would actually become bank 0.
This keeps the DMA-oriented allocation policy from de99f32635 while
preventing a too-small bank 0 from reaching place_dtb_initrd().
Make kernel_zimage_place_in_bank() return INVALID_PADDR when a
position-independent zImage cannot be placed in the supplied bank; the
real load path turns this into a panic, while the hwdom candidate check
uses it to reject the bank.
Fixes: de99f32635 ("device-tree: Improve hwdom memory allocation for DMA")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
The Arm zImage loader currently computes the kernel load address and
places the DTB/initrd in one local flow. The hardware-domain memory
allocator needs to reuse those placement rules before it chooses bank 0,
but open-coding the same calculations there would make the fix harder to
audit.
Split the existing logic into small helpers:
- kernel_zimage_place_in_bank() computes the zImage load address for a
given bank.
- first_bank_can_fit_modules() checks the aggregate first-bank
footprint.
- find_dtb_initrd_placement() chooses the DTB/initrd location within a
known bank and kernel range.
Rename place_modules() to place_dtb_initrd() so the code distinguishes
the kernel image from the DTB/initrd placement area. Also update the
comments linking the hypervisor and toolstack placement paths.
While moving the code, spell the 2MB alignment mask with MB(2) rather
than open-coding (2 << 20). This is mechanical and keeps the generated
value unchanged.
The caller still panics in the same cases as before, so this is intended
to be behavior preserving.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
The number of vCPUs requested for a boot-time Arm domain is not bounded
solely by Xen's generic domain limits. For GICv3 domains using the host
memory layout, Xen can only create vCPUs whose virtual redistributor
frame is covered by redistributor MMIO regions exposed for that layout.
This can affect the hardware domain and direct-mapped domains. Document
the GICv3-specific limit in the `cpus` property description in the Arm
device-tree booting guide. Also add a generic domain-limit caveat to the
`dom0_max_vcpus` command-line documentation.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
The vGIC per-vCPU init callback can fail. In particular, GICv3 rejects
a vCPU when the domain's redistributor layout has no MMIO slot covering
that vCPU. However, the generic vGIC init path ignored the callback
return value, so vcpu_create() could succeed with an invalid vGICv3
per-vCPU state.
This can be reproduced on FVP Base RevC by exposing a 2 MiB GICv3
redistributor region to Dom0 and booting Xen with:
maxcpus=1 dom0_max_vcpus=64
The host GICv3 redistributor range is:
region 0: 0x0000002f100000 - 0x0000002f300000
With Xen's guest redistributor frame size of 128 KiB, that range covers
16 guest redistributors. vCPU16 and above have no corresponding
redistributor slot.
Before this fix, Xen detected the missing redistributors:
d0: Unable to find a re-distributor for VCPU 16
...
d0: Unable to find a re-distributor for VCPU 63
but ignored the error and continued as if the secondary vCPUs had been
created correctly. Dom0 then saw 64 possible CPUs and could hang during
secondary CPU bring-up:
smp: Bringing up secondary CPUs ...
d0v15: vGICR: SGI: unhandled word write ... to ICACTIVER0
Propagate the vGIC vcpu_init() error so the caller can stop creating
secondary vCPUs. With this fix, Dom0 construction reports:
d0: Unable to find a re-distributor for VCPU 16
Failed to allocate d0v16
and the guest continues booting with the vCPUs created before the
failure:
smp: Brought up 1 node, 16 CPUs
Free the private IRQ rank allocated by vcpu_vgic_init() on this error
path. The caller will still run the generic vCPU creation cleanup, but
XFREE() clears the pointer so that cleanup remains idempotent.
Also fix the host-layout redistributor region count for the case where
the requested vCPU count is larger than the capacity of all host
redistributor regions. The old code always stored i + 1 after the loop.
That is correct when the loop stops inside a valid region because the
requested vCPU count is covered. If the loop exits after consuming all
hardware regions, i is already equal to the number of allocated regions,
so i + 1 records one region too many.
In the same FVP setup, that off-by-one made Xen describe host-layout
GICR state beyond the populated redistributor region list. Dom0 then
accessed the GICR MMIO window described in its device tree, but Xen could
not match the access to a valid emulated redistributor frame. During
debugging this was seen as an unexpected vGICR access followed by a
guest panic:
d0v0: vGICR: unknown gpa read address 000000002f10ffe8
pc : gic_iterate_rdists+0x4c/0x104
Kernel panic - not syncing: Attempted to kill the idle task!
Keep the existing construct_domain() policy used by Dom0 and dom0less
domain construction: a failure to create a secondary vCPU stops the
secondary vCPU creation loop, but does not fail the whole domain
construction.
Fixes: ea37fd2111 ("xen/arm: split vgic driver into generic and vgic-v2 driver")
Fixes: 54ec59f6b0 ("xen/arm: vgic-v3: Don't create empty re-distributor regions")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
get_llc_way_size() currently scans CLIDR_EL1 Ctype fields from the
highest level downwards and stops at the first unified cache it finds.
However, CLIDR_EL1 describes the cache hierarchy from Ctype1 upwards.
Arm ARM DDI 0487J.a, D19.2.27 says that once software has seen a
Ctype value of 0b000 while reading from Ctype1 upwards, no caches
manageable by the architected set/way maintenance instructions exist at
further-out levels, and the higher Ctype fields must be ignored.
The current reverse scan can therefore select a unified cache level from
a Ctype field above the first no-cache level. Such a field is not part of
the architecturally described CLIDR/CCSIDR cache hierarchy and should not
be used for selecting the CCSIDR level.
Scan Ctype fields from L1 upwards, stop at the first no-cache level, and
keep the outermost unified cache observed before that point.
This preserves the result for regular cache hierarchies, while avoiding
selection of an architecturally ignored Ctype field.
Fixes: f4985fce6f ("xen/arm: add initial support for LLC coloring on arm64")
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>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
gicv3_dist_init() disables the distributor before reprogramming the
global interrupt state. It used to do this by writing 0 to GICD_CTLR.
On a system where firmware has already enabled Non-secure affinity
routing, a zero write clears the Non-secure view's GICD_CTLR.ARE_NS bit.
Arm IHI 0069H.b, section 2.3.3 ("Changing affinity routing enables"),
states that changing GICD_CTLR.ARE_NS from 1 to 0 is UNPREDICTABLE. The
GICD_CTLR register description in section 12.9.4 carries the same rule
for the ARE_NS field.
Preserve ARE_NS while clearing the group enable bits. If firmware left
ARE_NS clear, the value written is still 0, preserving the existing
initialization flow.
Fixes: bc183a0235 ("xen/arm: Add support for GIC v3")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
parse_color_config() currently accepts delimiters where a color value
is expected because simple_strtoul() returns zero without advancing the
input pointer. This makes strings such as ",2-6", "-10,19-20" or
"1,,2" look as if an empty value was color 0.
Also fix the DT color parsing error message by adding the missing
newline and including the domain ID, matching the style of the color
validation error below.
Fixes: 6cdea3444e ("xen/arm: add Dom0 cache coloring support")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
parse_color_config() updates the caller-provided color count while
parsing. If parsing later fails, leave the count at zero so callers
do not consume a partially parsed configuration.
The bug is reachable in practice: cmdline_parse() ignores the -EINVAL
from a custom_param callback, so boot continues with the partial
xen_num_colors / dom0_num_colors that llc_coloring_init() and
dom0_set_llc_colors() then consume.
Fixes: 6cdea3444e ("xen/arm: add Dom0 cache coloring support")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
gicv3_do_wait_for_rwp() is used for both distributor and
redistributor writes. The CTLR register is at offset 0 for both,
but the RWP bit is not in the same position.
For GICD_CTLR, RWP is bit 31. For GICR_CTLR, bit 31 is UWP,
while RWP is bit 3. The redistributor wait path was therefore
polling UWP instead of RWP.
UWP covers upstream writes, including Generate SGI packets, and is
not a substitute for redistributor register write completion. The
existing redistributor callers need RWP semantics for redistributor
register writes such as GICR_ICENABLER0 and GICR_CTLR updates.
Add GICR_CTLR_RWP and pass the expected RWP bit to the shared
helper.
Fixes: bc183a0235 ("xen/arm: Add support for GIC v3")
Reported-by: Luca Fancellu <luca.fancellu@arm.com>
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
GITS_CBASER.InnerCache uses the GIC BASER cacheability encoding.
Both 0b000 (Device-nGnRnE) and 0b001 (Normal Inner
Non-cacheable) describe non-cacheable accesses to the command queue.
its_map_cbaser() only checked whether the shifted field was zero,
so an ITS that reports Normal Inner Non-cacheable would not set
HOST_ITS_FLUSH_CMD_QUEUE. Decode the field before comparing it with
the unshifted enum value, matching the handling of ITS BASER tables
and GICR_PROPBASER.
Fixes: 8ed8d21373 ("ARM: GICv3 ITS: map ITS command buffer")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
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>
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>
gicv3_cpu_disable() currently writes 0 to ICC_CTLR_EL1. Unlike
GICC_CTLR in the GICv2 path, ICC_CTLR_EL1 does not enable or disable
physical Group 1 interrupt signalling, so this write only clears
EOImode.
The GICv3 power management rules require the physical group enables in
the CPU interface to be cleared before the redistributor is driven into
ProcessorSleep, otherwise behaviour is UNPREDICTABLE. Xen only enables
Group 1 interrupts on this path, so disable the interface by clearing
ICC_IGRPEN1_EL1 instead.
This appears to be a copy of the GICv2 pattern where the enable control
lives in CTLR, but for GICv3 the enable moved to ICC_IGRPEN1_EL1.
Fixes: bc183a0235 ("xen/arm: Add support for GIC v3")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Mention the newly added support for guest suspend and resume to/from
RAM via vPSCI on Arm platforms.
This support is limited to non-hardware domain guests.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Add a new entry under the "Virtual Hardware, Hypervisor" section
documenting support for the optional PSCI SYSTEM_SUSPEND function
exposed to guests.
This function is available via the virtual PSCI interface and allows
guest domains (domUs) to initiate system suspend operations.
The feature is currently marked as "Tech Preview".
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Acked-by: Julien Grall <jgrall@amazon.com>
The "xl resume" command was previously excluded from Arm builds because
system suspend/resume (e.g., SYSTEM_SUSPEND via vPSCI) was not
implemented. On x86, this command is used for resume.
This change enables compilation of `xl resume` on Arm regardless of the
underlying implementation status, making the tool available for testing
and future feature support. The relevant libxl infrastructure and handler
functions are already present and usable.
Note: This does not imply full system suspend/resume support on Arm.
The `xl suspend` command still does not work on Arm platforms.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
Add support for the PSCI SYSTEM_SUSPEND function in the vPSCI interface,
allowing guests to request suspend via the PSCI v1.0+ SYSTEM_SUSPEND call
(both 32-bit and 64-bit variants).
Implementation details:
- Add SYSTEM_SUSPEND function IDs to PSCI definitions
- Trap and handle SYSTEM_SUSPEND in vPSCI
- Reject SYSTEM_SUSPEND for the hardware domain to avoid host shutdown
- Require all secondary VCPUs to be offline before suspend
- Split arch_set_info_guest() into arch_vcpu_validate_guest_context() and
arch_vcpu_apply_guest_context() for reuse by vPSCI
- Add vpsci_build_guest_context() helper and store prevalidated context in
resume_ctx; resume applies it and frees it
- Add arch_domain_resume() function is an architecture-specific hook that
is invoked during domain resume to perform any necessary setup or
restoration steps required by the platform.
Usage:
For Linux-based guests, suspend can be initiated with:
echo mem > /sys/power/state
or via:
systemctl suspend
Resume from control domain:
xl resume <domain>
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Keep the pkg-config lookup for SYSTEMD_SLEEP_DIR, but fall back to
"$(prefix)/lib/systemd/system-sleep/" if the variable remains unset.
This avoids reintroducing a build-time dependency on systemd-devel while
still honoring the path provided by pkg-config when present.
Fixes: e54a6cd6a1 ("systemd: Add hooks to stop/start xen-watchdog on suspend/resume")
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
If init_one_irq_desc() fails, init_local_irq_data() returns without
releasing local_irqs_type_lock, leading to a possible deadlock.
Release the lock before returning to ensure proper cleanup.
Fixes: 2bb32b8092 ("xen/irq: Propagate the error from init_one_desc_irq() in init_*_irq_data()")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Acked-by: Julien Grall <jgrall@amazon.com>
This patch adds a systemd sleep hook script to stop the xen-watchdog
service before system suspend and start it again after resume.
Stopping the watchdog before a system suspend operation may look unsafe.
Let's imagine the following situation: 'systemctl suspend' does not
interact with the running service at all. In such a case, the Xen
watchdog daemon freezes just before suspend. If this happens, for
example, right before sending a ping, and Xen has not yet marked the
domain as suspended (is_shutting_down), the Xen watchdog timer may
trigger a false alert.
This is an almost impossible situation, because typically:
ping time = watchdog timeout / 2
and the watchdog timeout is usually set to a relatively large value
(dozens of seconds).
Still, this is more likely with very short watchdog timeouts. It may
happen in the following scenarios:
* Significant delays occur between freezing Linux tasks and
triggering the ACPI or PSCI sleep request or handler.
* Long delays happen inside Xen between the entrance to the sleep
trigger and the actual forwarding of the sleep request further.
A similar situation may occur on resume with short timeouts. During the
resume operation, Xen restores timers and the domain context. The Xen
watchdog timer also resumes. If it schedules the domain right before the
watchdog timeout expires, and the daemon responsible for pinging is not
yet running, a timeout might occur.
Both scenarios are rare and typically require very small watchdog
timeouts combined with significant delays in Xen or the Linux kernel
during suspend/resume flows.
Conceptually, however, if activating and pinging the Xen watchdog is the
responsibility of the domain and its services, then the domain should
also manage the watchdog service/daemon lifecycle. This is similar to
what is already done by the Xen watchdog driver inside the Linux kernel.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Add a new entry under "Virtual Hardware, Hypervisor" for guest PSCI
support on ARM. This documents support for all mandatory functions of
PSCI 1.1, and separately lists the supported optional functions.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
This patch wraps the suspend/resume console callbacks and related code within
CONFIG_SYSTEM_SUSPEND blocks. This ensures that these functions and their
calls are only included in the build when CONFIG_SYSTEM_SUSPEND is enabled.
This addresses Misra Rule 2.1 violations.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
This patch adds CONFIG_SYSTEM_SUSPEND guards around freeze_domains
and thaw_domains functions.
This ensures they are only compiled into the hypervisor when the system
suspend functionality is enabled, aligning their inclusion with their
specific use case.
This addresses two Misra Rule 2.1 violations.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Add missing input register descriptions to enable_secondary_cpu_mm
and enable_boot_cpu_mm functions. This update improves code clarity
and consistency in comments.
No functional changes are introduced by this patch.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Corrected a typo in a comment within vpsci.c:
replaced "SCCC_SMCCC_*_REVISION" with the correct "SSSC_SMCCC_*_REVISION".
This change improves clarity but does not affect functionality.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
... and into their parent, enter_state(). This change addresses the concern
about misleading function semantics, as the scheduler operations are not
directly related to the domain pausing/resuming implied by the freeze/thaw
naming.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Mykola Kvach