ui/input: do not assert() when tracing invalid input
It's possible to reach an assert() in the input tracing code by sending
some out of range input values via D-Bus for ex:
#0 0x00007fec8652186c in __pthread_kill_implementation () at /lib64/libc.so.6
#1 0x00007fec864c648e in raise () at /lib64/libc.so.6
#2 0x00007fec864ad7b3 in abort () at /lib64/libc.so.6
#3 0x00007fec864ae804 in __libc_message_impl.cold () at /lib64/libc.so.6
#4 0x00007fec864be345 in __assert_fail () at /lib64/libc.so.6
#5 0x00005597964c551e in qapi_enum_lookup[cold] ()
#6 0x000055979650514a in qemu_input_event_send_impl ()
#7 0x0000559796505a4d in qemu_input_queue_btn ()
#8 0x00007fec85780c19 in dbus_mouse_press () at /usr/bin/../lib64/qemu/ui-dbus.so
#9 0x00007fec857912fc in _g_dbus_codegen_marshal_BOOLEAN__OBJECT_UINT.part.0 () at /usr/bin/../lib64/qemu/ui-dbus.so
#10 0x00007fec874cce7c in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#11 0x00007fec874eb849 in signal_emit_unlocked_R.isra.0 () at /lib64/libgobject-2.0.so.0
#12 0x00007fec874ec66f in g_signal_emitv () at /lib64/libgobject-2.0.so.0
#13 0x00007fec85797e0a in _qemu_dbus_display1_mouse_skeleton_handle_method_call () at /usr/bin/../lib64/qemu/ui-dbus.so
Other paths in input code accept out-of-range values
(qemu_input_key_value_to_number etc). Let it pass tracing.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Back in 2020, the dbus-vmstate test was disabled by commit d46f81cb74
("tests: Disable dbus-vmstate-test") due to Patchew failures. We don't
use Patchew anymore for CI, so re-enable the test.
tests/qtest/dbus-vmstate: Stop the daemons explicitly
The dbus-vmstate test is currently non-deterministically emitting a
"cleaning up pid" message, followed by the PID of one of the
dbus-daemon processes used during the test. This is due to a race
between the GTestDBus g_autoptr destructor and a child process that
does cleanup when the program ends.
Add calls to g_test_dbus_down() to make the issuance of the SIGTERM to
the dbus-daemon deterministic.
tests/qtest/dbus-vmstate: Mute Glib complaints about g_unsetenv thread-safety
TLDR: GLib is bugged, the dbus-vmstate-test spams debug messages
unconditionally. Mute them.
GLib is trying to protect against the lack of thread-safety of
setenv/unsetsenv functions by warning when those functions were
invoked after a thread has been started.
https://gitlab.gnome.org/GNOME/glib/issues/715
Unfortunately:
1) GLib itself starts a thread pool via _g_dbus_initialize when
working around a bug in its type dependency chain. This happens in
many places, but the test triggers it via
g_dbus_address_get_for_bus_sync.
https://bugzilla.gnome.org/show_bug.cgi?id=627724
2) GLib itself calls g_unsetenv after the test calls g_test_dbus_up.
3) The debug message at g_unsetenv is issued to the G_LOG_DOMAIN
defined while compiling the library, i.e "GLib", but this domain is
never initialized, so the log functions go into a fallback chain that
results in ignoring the G_MESSAGES_DEBUG environment variable, causing
the debug messages to not be suppressed when they should.
Mute the messages by implementing a handler for G_LOG_LEVEL_DEBUG
in the "GLib" log domain and honoring G_MESSAGES_DEBUG.
tests/qtest/dbus-vmstate: Bring the test up-to-date
The dbus-vmstate-test has been disabled for years. Here's the things
that have changed in the meantime and how to update the test:
- Migration tests got new headers.
Update the includes.
- migrate_qmp got new parameters.
Update the caller.
- migrate_incoming_qmp is now used instead of -incoming URL.
Use -incoming defer.
- Tests expecting failure should not check non-zero return code.
Check for failed migration state instead.
- The test result enum was introduced.
Replace the migration_fail flag with the enum.
- The DEVICE state was added.
Replace wait_for_migration_complete with migration_event_wait, which
won't trip on intermediary states.
- Migration completion was reworked.
Explicitly wait for the RESUME event before asserting runstate is
RUNNING to avoid checking too quickly and seeing FINISH_MIGRATE
instead.
- The FAILING state was added.
Wait for it before waiting for the RESUME event.
- Sanity checks were added to migration_get_env().
Start calling that function in main.
- qtest_add_func now has a wrapper.
Replace qtest_add_func with migration_test_add. Update tests'
signatures to take MigrationCommon, although it's unused.
- meson now sets up G_TEST_DBUS_DAEMON.
Remove the logic around it.
Stefan Hajnoczi [Wed, 15 Apr 2026 23:29:06 +0000 (19:29 -0400)]
scsi: handle reservation changes across migration
Other nodes in the cluster can preempt or clear SCSI Persistent
Reservations at any time. When this happens across live migration, the
reservation state transferred with the guest might be outdated.
Attempt to handle such cases gracefully by checking the current
reservation or registered keys to detect stale state before restoring.
If the actual state of the disk has changed, do not modify it and accept
that as the most up-to-date state.
Do this using READ RESERVATION when the guest holds a reservation or
READ KEYS when the guest has registered a key but does not hold a
reservation.
There is still a race condition between checking and restoring state,
but it seems unavoidable and is no worse than before.
Stefan Hajnoczi [Wed, 1 Apr 2026 17:19:27 +0000 (13:19 -0400)]
scsi: register again after PREEMPT without reservation
The SCSI specification says PREEMPT without a reservation removes all
registrations with the given key. Try to register again after PREEMPT
since our key will have been removed.
In practice some SCSI targets keep the calling I_T nexus' registration
instead of removing it. Therefore we need to handle both the
spec-compliant and the non-compliant behavior.
Stefan Hajnoczi [Wed, 1 Apr 2026 17:19:26 +0000 (13:19 -0400)]
scsi: always send valid PREEMPT TYPE field
The SPC-6 specification says that the PREEMPT service action ignores the
TYPE field when there is no reservation. However, the LIO Linux iSCSI
target rejects commands with a zero TYPE field. The field never ends up
being used in this case, so replace it with a "valid" value to work
around the issue.
Stefan Hajnoczi [Wed, 15 Apr 2026 23:29:05 +0000 (19:29 -0400)]
scsi: change buf_size to unsigned int in scsi_SG_IO()
SG_IO supports an unsigned int dxfer_len value. Existing callers use
less than 256 bytes, so scsi_SG_IO()'s uint8_t buf_size type was
sufficient. The next patch will use a larger value, so update the type.
The length passed in is in bytes not characters. Rename the
parameters to make that clear. Calculate the number of chars
if needed. Fix length checks to use the number of chars not
bytes to avoid OOB reads.
The buffer size checks do not consider the mm_header size, simliar to
CVE-2026-5744. Factor out the repeated size check to a small helper
function, fix the check, update all places to use the new helper.
Song Gao [Thu, 16 Apr 2026 11:47:15 +0000 (19:47 +0800)]
target/loongarch: Add support for dbar hint variants
LoongArch architecture (since LA664) introduces fine-grained dbar
hints that allow controlling which memory accesses are ordered by
the barrier. Previously, all dbar instructions were treated as a
full barrier (TCG_MO_ALL | TCG_BAR_SC).
This patch adds support for decoding dbar hints and emitting the
appropriate TCG memory barrier flags. For CPUs that do not advertise
the DBAR_HINTS feature (cpucfg3.DBAR_HINTS = 0), all dbar hints
fall back to a full barrier, preserving compatibility.
The hint encoding follows the LoongArch v1.10 specification:
The hint is a 5-bit field (bits 4-0). Bit4 is reserved and currently
ignored/discarded. Only bits 3-0 are used for ordering control.
* Bit3: barrier for previous read (0: true, 1: false)
* Bit2: barrier for previous write (0: true, 1: false)
* Bit1: barrier for succeeding read (0: true, 1: false)
* Bit0: barrier for succeeding write (0: true, 1: false)
The mapping to TCG memory order flags is as follows:
TCG_BAR_SC |TCG_MO_LD_LD | TCG_MO_LD_ST;
TCG_BAR_SC |TCG_MO_ST_LD | TCG_MO_ST_ST;
TCG_BAR_SC |TCG_MO_LD_LD | TCG_MO_ST_LD;
TCG_BAR_SC |TCG_MO_ST_ST | TCG_MO_LD_ST;
Special hint handling:
- hint 0x700: LL/SC loop barrier, treated as a full barrier as recommended.
- hint 0xf and 0x1f: reserved/no-op, treated as no operation
Signed-off-by: Song Gao <gaosong@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
The BCM2835 RNG has 32-bit registers only; specify this in
the MemoryRegionOps so wrong-sized accesses are rejected rather
than getting to the assertions in the read and write functions,
and for clarity add the matching .impl constraints.
Peter Maydell [Tue, 5 May 2026 10:37:26 +0000 (11:37 +0100)]
target/arm: Report IL=0 for Thumb 16-bit BKPT insn
The Thumb BKPT insn is 16-bit, and the ESR_ELx syndrome register
definition requires that we set the IL bit to 0 for this, and 1 for
the 32-bit A32 and A64 BKPT/BRK.
We used to do this correctly, but accidentally lost it in the
conversion to decodetree, because we converted the A32 BKPT first,
and then when we converted the T16 BKPT we forgot that trans_BKPT()
was unconditionally setting IL=1.
Pass the right value for syn_aa32_bkpt()'s is_16bit argument.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3474 Fixes: 43f7e42c7d515f ("target/arm: Convert T16, Miscellaneous 16-bit instructions") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260505103726.419195-1-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:17:00 +0000 (11:17 +0000)]
hw/arm/virt: Allow user to select GICv5
Allow the user to select a GICv5 via '-machine gic-version=x-5', and
document this. The 'x-' prefix indicates that the emulation is still
in an "experimental" state as far as QEMU is concerned; the
documentation describes what "experimental" means for the user and
what parts are not yet implemented.
We do not make 'gic-version=max' enable GICv5 here because:
* the GICv5 architectural spec is still at the EAC level and could
have minor changes between now and its final version; only users
who specifically want to start working with the GICv5 should
select it
* QEMU's implementation here is still not fully featured, and
selecting it instead of GICv3 will mean losing functionality such
as MSIs
* the GICv5 is not backwards compatible with the GICv3/GICv4 for
system software, so silently "upgrading" an existing command line
to GICv5 is just going to break existing guest kernels
The last one in particular suggests that even when the emulation
moves out of "experimental" status we will probably not want to
change "max".
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260327111700.795099-66-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:59 +0000 (11:16 +0000)]
hw/arm/virt: Enable GICv5 CPU interface when using GICv5
If we are using the GICv5 in the virt board, we need to set the
has_gcie property on the CPU objects to tell them to implement the
cpu interface part of GICv5.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-65-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:58 +0000 (11:16 +0000)]
hw/arm/virt: Use correct interrupt type for GICv5 SPIs in the DTB
The GICv5 devicetree binding specifies that the "interrupts" property
for devices connected to it should use the architectural INTID.TYPE
values to specify whether the interrupt is an SPI, LPI or PPI. This
is different to the GICv2 and GICv3, so instead of hardcoding the
GIC_FDT_IRQ_TYPE_SPI constant when we create "interrupts" bindings,
create a new function gic_fdt_irq_type_spi() that returns the right
value for the interrupt controller in use.
For SPIs, the INTID.ID and the trigger-mode fields of the
"interrupts" property remain the same for GICv5 and the older GIC
versions.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-64-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:57 +0000 (11:16 +0000)]
hw/arm/virt: Handle GICv5 in interrupt bindings for PPIs
The GICv5 devicetree binding specifies the "interrupts" property
differently to GICv2 and GICv3 for PPIs: the first field is the
architectural INTID.TYPE, and the second is the architectural
INTID.ID. (The third field defining the level/edge trigger mode has
the same values for GICv5 as it did for the older GICs.)
In the places in the virt board where we wire up PPIs (the timer and
the PMU), handle the GICv5:
* use the architectural constant GICV5_PPI for the type
* use the architected GICv5 PPI numbers for the interrupt sources
(which differ from the old ones and don't need to be adjusted via
INTID_TO_PPI())
* leave the irqflags as-is
Add some commentary in our include/hw/arm/fdt.h file about what the
the constants defined there are valid for.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-63-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:56 +0000 (11:16 +0000)]
hw/arm/virt: Advertise GICv5 in the DTB
Advertise the GICv5 in the DTB. This binding is final as it is in
the upstream Linux kernel as:
Documentation/devicetree/bindings/interrupt-controller/arm,gic-v5.yaml
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260327111700.795099-62-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:55 +0000 (11:16 +0000)]
hw/arm/virt: Create and connect GICv5
In this commit we create and connect up the GICv5. We do not
advertise it in the ACPI tables or DTB; that will be done in a
following commit.
The user-facing gic-version property still only documents and permits
in its setter function the existing set of possible values; we won't
permit the user to select a GICv5 until all the code to handle it is
in place.
Although we currently implement only the IRS, and only for EL1,
we reserve space in the virt board's memory map now for all the
register frames that the GICv5 may use. Each interrupt domain has:
* one IRS config register frame
* one ITS config register frame
* one ITS translate register frame
and each of these frames is 64K in size and 64K aligned and must be
at a unique address (that is, it is not permitted to have all the IRS
config register frames at the same physical address in the different
S/NS/etc physical address spaces).
The addresses and layout of these frames are entirely up to the
implementation: software will be passed their addresses via firmware
data structures (ACPI or DTB).
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260327111700.795099-61-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:54 +0000 (11:16 +0000)]
hw/arm/virt: Split GICv2 and GICv3/4 creation
Currently create_gic() handles GICv2 and GICv3/4 in a single
function, with large sections that are conditional on the
vms->gic_version. GICv5 will be different to both.
Refactor into create_gicv2() and create_gicv3().
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-60-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:53 +0000 (11:16 +0000)]
hw/arm/virt: Pull "wire CPU interrupts" out of create_gic()
create_gic() is quite long and mixes GICv2 and GICv3 even though
they're mostly different in their creation. As a preliminary to
splitting it up, pull out the "wire the CPU interrupts to the GIC PPI
inputs" code out into its own function. This is a long and
self-contained piece of code that is the main thing that we need to
do basically the same way for GICv2 and GICv3.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260327111700.795099-59-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:52 +0000 (11:16 +0000)]
hw/arm/virt: Move MSI controller creation out of create_gic()
The create_gic() function also creates the MSI controller; however
there isn't really a strong linkage here, and for the GICv5 it will
be more convenient to separate it out. Move it to a new
create_msi_controller() function.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260327111700.795099-58-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:51 +0000 (11:16 +0000)]
hw/arm/virt: Remember CPU phandles rather than looking them up by name
In fdt_add_cpu_nodes(), we currently add phandles for each CPU node
if we are going to add a topology description, and when we do, we
re-look-up the phandle by node name when creating the topology
description.
For GICv5 we will also want to refer to the CPU phandles; so always
add a phandle, and keep track of those phandles in the
VirtMachineState so we don't have to look them up by name in the dtb
every time.
The phandle property is extra data in the final DTB, but only a tiny
amount, so it's not worth trying to carefully track the conditions
when we're going to need them so we only emit them when required.
(We need to change the smp_cpus variable to unsigned because
otherwise gcc thinks that we might be passing a negative number to
g_new0() and produces an error:
/usr/include/glib-2.0/glib/gmem.h:270:19: error: argument 1 range [18446744071562067968, 18446744073709551615] exceeds maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=]
270 | __p = g_##func##_n (__n, __s); \
| ^~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gmem.h:332:57: note: in expansion of macro ‘_G_NEW’
332 | #define g_new0(struct_type, n_structs) _G_NEW (struct_type, n_structs, malloc0)
| ^~~~~~
../../hw/arm/virt.c:469:25: note: in expansion of macro ‘g_new0’
469 | vms->cpu_phandles = g_new0(uint32_t, smp_cpus);
| ^~~~~~
)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-57-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:50 +0000 (11:16 +0000)]
hw/intc/arm_gicv3_cpuif: Don't allow GICv3 if CPU has GICv5 cpuif
The GICv3 and GICv5 CPU interfaces are not compatible, and a CPU will
only implement either one or the other. If we find that we're trying
to connect a GICv3 to a CPU that implements FEAT_GCIE, fail. This
will only happen if the board code has a bug and doesn't configure
its CPUs and its GIC consistently.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-56-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:49 +0000 (11:16 +0000)]
target/arm: Add has_gcie property to enable FEAT_GCIE
Add a has_gcie QOM property to the CPU which allows the board code to
enable FEAT_GCIE, the GICv5 CPU interface.
Enabling the GICv5 CPU interface comes with a significant
restriction: because the GICv5 architecture is Armv9, it assumes the
Armv9 requirement that only EL0 (userspace) may be in AArch32. So
there are no GIC control system registers defined for AArch32. We
force AArch32 at ELs 1, 2 and 3 to disabled, to avoid a guest being
able to get into an EL where interrupts are completely broken.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-55-peter.maydell@linaro.org
Peter Maydell [Thu, 7 May 2026 14:14:57 +0000 (15:14 +0100)]
target/arm: Connect internal interrupt sources up as GICv5 PPIs
The CPU has several interrupt sources which are exposed as GICv5
PPIs. For QEMU, this means the generic timers and the PMU.
In GICv3, we implemented these as qemu_irq lines which connect up to
the external interrupt controller device. In a GICv5, the PPIs are
handled entirely inside the CPU interface, so there are no external
signals. Instead we provide a gicv5_update_ppi_state() function
which the emulated timer and PMU code uses to tell the CPU interface
about the new state of the PPI source.
We make the GICv5 function a no-op if there is no GICv5 present, so
that calling code can do both "update the old irq lines" and "update
the GICv5 PPI" without having to add conditionals. (In a GICv5
system the old irq lines won't be connected to anything, so the
qemu_set_irq() will be a no-op.)
Updating PPIs via either mechanism is unnecessary in user-only mode;
we got away with not ifdeffing this away before because
qemu_set_irq() is built for user-only mode, but since the GICv5 cpuif
code is system-emulation only, we do need an ifdef now.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-54-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:47 +0000 (11:16 +0000)]
target/arm: GICv5 cpuif: Signal IRQ or FIQ
The CPU interface must signal IRQ or FIQ (possibly with
superpriority) when there is a pending interrupt of sufficient
priority available. Implement this logic.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-53-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:46 +0000 (11:16 +0000)]
target/arm: GICv5 cpuif: Implement GIC CDDI
Implement the GIC CDDI system instruction, which deactivates the
specified interrupt.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-52-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:45 +0000 (11:16 +0000)]
hw/intc/arm_gicv5: Implement Deactivate command
Implement the equivalent of the GICv5 stream protocol's Deactivate
command, which lets the cpuif tell the IRS to deactivate the
specified interrupt.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-51-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:44 +0000 (11:16 +0000)]
target/arm: GICv5 cpuif: Implement GIC CDEOI
Implement the GIC CDEOI instruction, which performs a "priority
drop", clearing the highest set bit in the APR register.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-50-peter.maydell@linaro.org
The GICR CDIA system instruction is what the guest uses to
acknowledge the highest priority pending interrupt. It returns a
value corresponding to the HPPI for the current physical interrupt
domain, if any, and moves that interrupt to being Active.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-49-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:42 +0000 (11:16 +0000)]
hw/intc/arm_gicv5: Implement Activate command
Implement the equivalent of the GICv5 stream protocol's Activate
command, which lets the cpuif tell the IRS to move its current
highest priority pending interrupt into the Active state, and to
clear the Pending state for an Edge handling mode interrupt.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-48-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:41 +0000 (11:16 +0000)]
target/arm: GICv5 cpuif: Implement ICC_HPPIR_EL1
Implement ICC_HPPIR_EL1, which the guest can use to read the current
highest priority pending interrupt. Like APR, PCR and CR0, this is
banked, with the _EL1 register reading the answer for the current
logical interrupt domain, and the _EL3 register reading the answer
for the EL3 interrupt domain.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-47-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:40 +0000 (11:16 +0000)]
target/arm: GICv5 cpuif: Implement ICC_PCR_EL1
Implement the ICC_PCR_* registers. These hold the physical priority
mask for each interrupt domain -- an HPPI is only sufficiently high
priority to preempt if it is higher priority than this mask value.
Here we just implement the access to this data.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-46-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:39 +0000 (11:16 +0000)]
target/arm: GICv5 cpuif: Implement ICC_CR0_EL1
Implement ICC_CR0_EL1, which is the main control register. This is
banked between interrupt domains in the same way as ICC_APR_*.
The GICv5 spec assumes that typically there will need to be a
hardware handshake between the CPU and the IRS, which is kicked off
by guest software setting a LINK bit in this register to bring the
link between the two online. However it is permitted to have an
implementation where the link is permanently up. We take advantage
of this, so our LINK and LINK_IDLE bits are read-only and always 1.
This means the only interesting bit in this register for us is the
main enable bit: when disabled for a domain, the cpuif considers that
there is never an available highest priority interrupt.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-45-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:38 +0000 (11:16 +0000)]
hw/intc/arm_gicv5: Calculate HPPI in the IRS
The IRS is required to present the highest priority pending interrupt
that it has for each domain for each cpu interface. We implement
this in the irs_recalc_hppi() function, which we call at every point
where some relevant IRS state changes.
This function calls gicv5_forward_interrupt() to do the equivalent of
the GICv5 stream protocol Forward and Recall commands. For the
moment we simply record the HPPI on the CPU interface side without
trying to process it; the handling of the HPPI in the cpuif will be
added in subsequent commits.
There are some cases where we could skip doing the full HPPI
recalculation, e.g. when the guest changes the config of an
interrupt that is disabled; we expect that the guest will only do
interrupt config at startup, so we don't attempt to optimise this.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-44-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:37 +0000 (11:16 +0000)]
target/arm: GICv5 cpuif: Calculate the highest priority PPI
When the state of PPIs changes, recalculate the highest priority PPI.
In subsequent commits we will use this cached value to provide the
HPPI info to the guest, decide whether to signal IRQ or FIQ, handle
interrupt acknowldge from the guest, and so on.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-43-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:36 +0000 (11:16 +0000)]
target/arm: GICv5 cpuif: Implement ICC_APR_EL1 and ICC_HAPR_EL1
The ICC_APR_EL1 GICv5 cpuif register records the physical active
priorities. Since the GICv5 always uses 5 bits of priority, this
register always has 32 non-RES0 bits, and we don't need the
complicated GICv3 setup where there might be 1, 2 or 4 APR registers.
ICC_HAPR_EL1 is a read-only register which reports the current
running priority. This is defined to be the lowest set bit (i.e.
the highest priority) in the APR, or the Idle priority 0xff if there
are no active interrupts, so it is effectively a convenience
re-presentation of the APR register data.
The APR register is banked per interrupt domain; ICC_APR_EL1 accesses
the version of the register corresponding to the current logical
interrupt domain. The APR data for the final domain (EL3) is
accessed via ICC_APR_EL3. Although we are starting with an EL1-only
implementation, we define the CPU state as banked here so we don't
have to change our representation of it later when we add EL3 and RME
support.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-42-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:35 +0000 (11:16 +0000)]
target/arm: GICv5 cpuif: Implement PPI priority registers
Implement the GICv5 registers which hold the priority of the PPIs.
Each 64-bit register has the priority fields for 8 PPIs, so there are
16 registers in total. This would be a lot of duplication if we
wrote it out statically in the array, so instead create each register
via a loop in define_gicv5_cpuif_regs().
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-41-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:34 +0000 (11:16 +0000)]
target/arm: GICv5 cpuif: Implement PPI enable register
Implement the GICv5 register which holds the enable state of PPIs:
ICC_PPI_ENABLER<n>_EL1.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-40-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:33 +0000 (11:16 +0000)]
target/arm: GICv5 cpuif: Implement PPI pending status registers
The GICv5 PPI pending status is handled by two registers, one of
which is write-1-to-set and one of which is write-1-to-clear. The
pending state is read-only for PPIs where the handling mode is Edge.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-39-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:32 +0000 (11:16 +0000)]
target/arm: GICv5 cpuif: Implement PPI handling mode register
In the GICv5 the handling mode of a PPI is not software configurable;
it is reported via read-only CPU interface registers ICC_PPI_HMR0_EL1
and ICC_PPI_HMR1_EL1.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-38-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:31 +0000 (11:16 +0000)]
target/arm: GICv5 cpuif: Implement GICv5 PPI active set/clear registers
In the GICv5 PPI state and control lives in the CPU interface; this
is different from the GICv3 where this was all in the redistributor.
Implement the access system registers for the PPI active state; this
is a pair of registers, one of which has "write 1 to clear" behaviour
and the other of which has "write 1 to set". In both cases, reads
return the current state.
We start here by implementing the accessors for the underlying state;
we don't yet attempt to do anything (e.g. recalculating the highest
priority pending PPI) when the state changes. That will come in
subsequent commits.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-37-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:30 +0000 (11:16 +0000)]
target/arm: GICv5 cpuif: Implement ICC_IDR0_EL1
ICC_IDR0_EL1 is an identification register; we can implement this as
a simple constant value.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-36-peter.maydell@linaro.org
The CPU system register ICC_IAFFIDR_EL1 is a read-only register that
tells the guest what the affinity ID of that CPU is.
Implement this register. In real hardware using the stream protocol,
the IRS tells the CPU its IAFFID using a DownstreamControl command as
part of the handshake process when the IRS-CPU link is brought
online. Our analogue of this is to pass the IAFFID as an extra
argument to gicv5_set_gicv5state(). (We could have the CPU call into
the GIC every time to ask for the value, but this would mean we had
to search the cpus[] array for the right CPU to return its IAFFID.)
Note that we don't put the IAFFID into the gicv5_cpuif sub-struct,
because that part of the CPU struct is zeroed on reset, and we must
keep the IAFFID across reset (we only set it up when the GIC device
is created).
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-35-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:28 +0000 (11:16 +0000)]
hw/intc/arm_gicv5: Cache pending LPIs in a hash table
The GICv5 stores information about LPIs in a guest-memory data
structure. Iterating through this to identify the highest priority
pending interrupt would be expensive; to avoid this we will use a
hash table which contains an entry for each pending LPI and which
caches the L2 ISTE. Typically only a few LPIs will be pending at any
one time, so iterating through the hash table should be fast.
We can access an L2 ISTE whenever it is valid, and can freely cache
the data for as long as the IST is valid. We only need to ensure
that we have written back the data at the point where
IRS_IST_BASER.VALID is written to 0.
We add an LPI to the cache when the pending bit is written to 1, and
remove it when it is written to 0. Handling of checking the cache,
and of adding and removing entries, is handled within get_l2_iste()
and put_l2_iste(), which all the operations that read and write ISTE
words use.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-34-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:27 +0000 (11:16 +0000)]
hw/intc/arm_gicv5: Implement CoreSight ID registers
The GICv5 register blocks all implement the usual Arm CoreSight ID
registers; implement these for the IRS. Although we only have one
callsite at the moment, the ITS config frame uses the same ID
register values, so we abstract this out into a function we can reuse
later.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260327111700.795099-33-peter.maydell@linaro.org
The IRS_PE_CR0, IRS_PE_SELR, IRS_PE_STATUSR registers allow software
to set and query per-CPU config. Software writes the AFFID of a CPU
to IRS_PE_SELR, and can then read and write the 1ofN config for that
CPU to IRS_PE_CR0, and read the CPU's online status from
IRS_PE_STATUSR.
For QEMU, we do not implement 1-of-N interrupt routing, so IRS_PE_CR0
can be RAZ/WI. Our CPUs are always online and selecting a new one
via SELR is instantaneous, so IRS_PE_STATUSR will return either
ONLINE | V | IDLE if a valid AFFID was written to SELR, or just IDLE
if an invalid AFFID was written.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-32-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:25 +0000 (11:16 +0000)]
hw/intc/arm_gicv5: Implement IRS_SYNCR and IRS_SYNC_STATUSR
The IRS_SYNCR register is used by software to request synchronization
of interrupt events. This means that in-flight interrupt events are
guaranteed to have been delivered.
Since QEMU's implementation is entirely synchronous, syncs are a
no-op for us. This means we can ignore writes to IRS_SYNCR and
always report "sync complete" via the IDLE bit in IRS_SYNC_STATUSR.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-31-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:24 +0000 (11:16 +0000)]
hw/intc/arm_gicv5: Implement IRS_CR0 and IRS_CR1
The IRS_CR0 register has the main enable bit for the IRS, and an IDLE
bit to tell the guest when an enable/disable transition has
completed.
The IRS_CR1 register has cacheability, shareability and cache hint
information to use for IRS memory accesses; since QEMU doesn't care
about this we can make it simply reads-as-written.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-30-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:23 +0000 (11:16 +0000)]
hw/intc/arm_gicv5: Update SPI state for CLEAR/SET events
When an SPI irq line changes level, this causes what the spec
describes as SET_LEVEL, SET_EDGE or CLEAR events. These also happen
when the trigger mode is reconfigured, or when software requests a
manual resample via the IRS_SPI_RESAMPLER register.
SET_LEVEL and SET_EDGE events make the interrupt pending, and update
its handler mode to match its trigger mode. CLEAR events make the
interrupt no longer pending.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-29-peter.maydell@linaro.org
Implement the IRS registers IRS_SPI_{SELR,STATUSR,CFGR,DOMAINR} which
form the config access for setting the trigger mode and domain of an
SPI. The way these work is that the guest writes the ID of the
interrupt it wants to configure to IRS_SPI_SELR, and then it can read
and write the trigger mode of that SPI via IRS_SPI_CFGR and the
domain via IRS_SPI_DOMAINR. IRS_SPI_STATUSR has a bit to indicate
whether the SPI is valid, and the usual IDLE bit to allow for
non-instantaneous updates (which QEMU doesn't do).
Since the only domain which can configure the domain of an SPI is EL3
and our initial implementation is NS-only, technically the DOMAINR
handling is unused code. However it is straightforward, being almost
the same as the CFGR handling, and we'll need it later on.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-28-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:21 +0000 (11:16 +0000)]
target/arm: GICv5 cpuif: Implement GIC CDRCFG and ICC_ICSR_EL1
Implement the GIC CDRCFG system instruction, which asks the IRS for
the configuration of an interrupt, and the system register
ICC_ICSR_EL1 which is where the answer is placed for the guest to
read it.
We mark ICC_ICSR_EL1 as ARM_CP_NO_RAW, because we do not want to have
this migrated as part of the generic "system register" migration
arrays. Instead we will do migration via a GICv5 cpuif vmstate
section. This is necessary because some of the cpuif registers are
banked by interrupt domain and so need special handling to migrate
the data in all the banks; it's also how we handle the gicv3 cpuif
registers. (We expect that KVM also will expose the cpuif registers
via GIC-specific ioctls rather than as generic sysregs.) We'll mark
all the GICv5 sysregs as NO_RAW.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-27-peter.maydell@linaro.org
Implement the gicv5_request_config() function, which corresponds to
the RequestConfig command and its RequestConfigAck reply.
We provide read_l2_iste() as a separate function to keep the "access
the in-guest-memory data structure" layer separate from the "operate
on the L2_ISTE values" layer.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260327111700.795099-26-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:19 +0000 (11:16 +0000)]
hw/intc/arm_gicv5: Make gicv5_set_* update SPI state
The GIC CD* insns that update interrupt state also work for SPIs.
Instead of ignoring the GICV5_SPI type in gicv5_set_priority() and
friends, update the state in our SPI state array.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260327111700.795099-25-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:18 +0000 (11:16 +0000)]
hw/intc/arm_gicv5: Create backing state for SPIs
The GICv5 allows an IRS to implement SPIs, which are fixed-wire
interrupts connected directly to the IRS. For QEMU we want to use
these for all our traditional fixed-wire interrupt devices. (The
other option the architecture permits is an Interrupt Wire Bridge
(IWB), which converts from a fixed-wire interrupt to an interrupt
event that is then translated through an ITS to send an LPI to the
ITS -- this is much more complexity than we need or want.)
SPI configuration is set via the same CPUIF instructions as LPI
configuration. Create an array of structs which track the SPI state
information listed in I_JVVTZ and I_BWPPP (ignoring for the moment
the VM assignment state, which we will add when we add virtualization
support).
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-24-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:17 +0000 (11:16 +0000)]
target/arm: GICv5 cpuif: Implement GIC CD* insns for setting config
Implement the GIC CDDIS, GIC CDEN, GIC CDAFF, GIC CDPEND and GIC CDHM
system instructions. These are all simple wrappers around the
equivalent gicv5_set_* functions, like GIC CDPRI.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-23-peter.maydell@linaro.org
Implement the GICv5 functions corresponding to the stream protocol
SetEnabled, SetPending, SetHandling, and SetTarget commands. These
work exactly like SetPriority: the IRS looks up the L2TE and updates
the corresponding field in it with the new value.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-22-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:15 +0000 (11:16 +0000)]
hw/intc/arm_gicv5: Implement IRS_MAP_L2_ISTR
The IRS register IRS_MAP_L2_ISTR is used by software to tell the IRS
that it has updated the address in an L1 IST entry to point to an
L2 IST. The sequence of events here is:
* software writes to L1_ISTE.L2_ADDR for some L1 ISTE which is
not valid (i.e. where L1_ISTE.VALID is 0); it leaves VALID at 0
* software writes to IRS_MAP_L2_ISTR with some INTID that is inside
the range for this L1 ISTE
* the IRS sets IRS_IST_STATUSR.IDLE to 0
* the IRS takes note of this information
* the IRS writes to the L1_ISTE to set VALID=1
* the IRS sets IRS_IST_STATUSR.IDLE to 1 to indicate that the
update is complete
For QEMU, we're strictly synchronous, so (as with IRS_IST_BASER
updates) we don't need to model the IDLE transitions and can have
IRS_IST_STATUSR always return IDLE=1. We also don't currently cache
anything for ISTE lookups, so we don't need to invalidate or update
anything when software makes the L2 valid.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-21-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:14 +0000 (11:16 +0000)]
target/arm: GICv5 cpuif: Implement the GIC CDPRI instruction
Implement the CPU interface GIC CDPRI instruction, which is a wrapper
around the SetPriority operation.
As with the barrier insns, we omit for the moment details which are
needed when the GICv5 supports virtualization:
* traps when legacy GICv3 emulation is enabled
* fine-grained-trap handling (which is done via
registers that are new in GICv5)
* sending the command for the virtual interrupt domain
when inside a guest
The CD instructions operate on the Current Physical Interrupt Domain,
which is the one associated with the current security state and
exception level. The spec also has the concept of a Logical
Interrupt Domain, which is the one associated with the security state
defined by SCR_EL3.{NS,NSE}. Mostly the logical interrupt domain is
used by the LD instructions, which are EL3-only; but we will also
want the concept later for handling some banked registers, so we
define functions for both.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-20-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:13 +0000 (11:16 +0000)]
hw/intc/arm_gicv5: Implement gicv5_set_priority()
Implement the gicv5_set_priority() function, which is our equivalent
of the Stream Protocol SetPriority command. This acts by looking the
interrupt ID up in the Interrupt State Table and storing the new
priority value into the table entry.
The memory transaction has to have the right transaction attributes
for the domain it is for; we precalculate these and keep them in the
GICv5ISTConfig.
The GIC has an optional software-error reporting mechanism via the
IRS_SWERR_* registers; this does not report all failure cases, only
those that would be annoying to detect and debug in some other way.
We choose not to implement this, but include some comments for
reportable error cases for future reference. Our LOG_GUEST_ERROR
logging is a superset of this.
At this point we implement only handling of SetPriority for LPIs; we
will add SPI handling in a later commit. Virtual interrupts aren't
supported by this initial EL1-only GICv5 implementation.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-19-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:12 +0000 (11:16 +0000)]
hw/intc/arm_gicv5: Cache LPI IST config in a struct
The IRS has multiple ISTs, for different contexts:
* physical LPIs (separately for each interrupt domain)
* virtual LPIs
* virtual SPIs
The config information for physical LPIs is in the IRS_IST_BASER and
IRS_IST_CFGR registers; for virtual LPIs and virtual SPIs it will be
in the L2_VMTE VM table entry. We would like to be able to write
generic code that can manipulate any of these ISTs. Define a struct
which captures the config information for an IST, and cache the
IRS_IST_CFGR/IRS_IST_BASER data into this format when the guest sets
the VALID bit.
This also allows us to enforce the correct handling of reserved and
out-of-range values, and expand the encodings of sizes into a more
convenient format for later use.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-18-peter.maydell@linaro.org
Implement the three registers that handle configuration of the
interrupt status table for physical LPIs:
* IRS_IST_BASER holds the base address of the table, and
has the VALID bit that tells the IRS to start using the config
* IRS_IST_CFGR has all the other config data for the table
* IRS_IST_STATUSR has the IDLE bit that tells software when
updates to IRS_IST_BASER have taken effect
Implement these registers. Note that neither BASER nor CFGR can be
written when VALID == 1, except to clear the VALID bit.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-17-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:10 +0000 (11:16 +0000)]
target/arm: Set up pointer to GICv5 in each CPU
The qdev link property array gives the IRS a pointer to each CPU that
is connected to it, but the CPU also needs a pointer to the IRS so
that it can issue commands. Set this up in a similar way to how we
do it for the GICv3: have the GIC's realize function call
gicv5_set_gicv5state() to set a pointer in the CPUARMState.
The CPU will only allow this link to be made if it actually
implements the GICv5 CPU interface; it will be the responsibility of
the board code to configure the CPU to have a GICv5 cpuif if it wants
to connect a GICv5 to it.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260327111700.795099-16-peter.maydell@linaro.org
Peter Maydell [Fri, 27 Mar 2026 11:16:09 +0000 (11:16 +0000)]
target/arm: GICv5 cpuif: Initial skeleton and GSB barrier insns
In the GICv5 architecture, part of the GIC is implemented inside the
CPU: this is the CPU interface, which presents software with system
instructions and system registers, and communicates with the external
part of the GIC (the Interrupt Routing Service, IRS) via an
architected stream interface where both sides can send commands and
receive responses.
Add the initial source files for the GICv5 CPU interface, with
initial content implementing just the two GSB GIC barrier
instructions, which are no-ops for QEMU.
Since we will not initially implement virtualization or the "legacy
GICv3" interface that can be provided to a VM guest, we don't have
the ICH_VCTLR_EL2 register and do not need to implement an accessfn
for the "trap if at EL1 and EL2 enabled and legacy GICv3 is enabled"
handling. We will come back and add this later as part of the
legacy-GICv3 code.
(The GICv3 has a similar architecture with part of the GIC being in
the CPU and part external; for QEMU we implemented the CPU interface
in hw/intc/, but in retrospect I think this was something of a design
mistake, and for GICv5 I am going to stick a bit closer to how the
hardware architecture splits things up; hence this code is in
target/arm.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-15-peter.maydell@linaro.org
projects / thirdparty / qemu.git / log
