hw/loongarch/virt: Define versioned virt machine

Add versioned virt machine started from QEMU 11.1

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>

hw/loongarch/virt: Define virt machine type with type_init()

Define virt machine with function type_init(), so that qemu versioned
virt machine can be added in later with similar method.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>

fpu: Return struct from parts{64,128}_addsub

At the same time, export.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Return struct from parts{64,128}_mul

At the same time, export.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Export parts{64,128}_compare

At the same time, constify the inputs.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Split scalbn from partsN(muladd_scalbn)

Handle the scaling separately with parts64_scalbn.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Introduce record_denormals_used

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Return struct from parts{64,128}_pick_nan_muladd

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Introduce parts64_round_to_fmt

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Export default_nan, pick_nan, return_nan routines

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Return struct from parts{64,128}_round_to_int

At the same time, export.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Return struct from parts{64,128}_div

At the same time, export.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Return struct from parts{64,128}_pick_nan

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Sink exp_bias adjustment in float64r32_pack_raw

Share the float32->float64 bias adjustment from both
the normal and denormal paths.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Return struct from parts{64,128}_return_nan

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Return struct from parts{64,128}_silence_nan

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Return struct from parts{64,128}_default_nan

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Export unpack_canonical and round_pack_canonical routines

Export the unpacking and repacking into the various formats.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Export FloatFmt structures

Export most of the FloatFmt structures.
Skip float16_params_ahp and the floatx80 precisions.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Split FloatParts{64,128} to softfloat-parts.h

Begin exposing the intermediate representation of softfloat.
Start with just the representation structures.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Mark pack_raw64 QEMU_ALWAYS_INLINE

This is almost always used with a constant FloatFmt,
so inlining pulls the constants into the shifts.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Mark unpack_raw64 QEMU_ALWAYS_INLINE

This is almost always used with a constant FloatFmt,
so inlining pulls the constants into the shifts.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Inline float64_pack_raw into callers

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Inline float32_pack_raw into callers

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Inline bfloat16_pack_raw into callers

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Inline float16_pack_raw into callers

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Inline float8_e5m2_pack_raw into single caller

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

fpu: Inline float8_e4m3_pack_raw to single caller

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

hw/misc/bcm2835_rng: Specify valid memory access sizes

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.

Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3394
Fixes: 54a5ba13a9f ("target-arm: Implement BCM2835 hardware RNG")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260501162700.4092512-1-peter.maydell@linaro.org

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

target/arm: GICv5 cpuif: Implement GICR CDIA command

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

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

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

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

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

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

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

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

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

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

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

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

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

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

target/arm: GICv5 cpuif: Implement ICC_IAFFIDR_EL1

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

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

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

hw/intc/arm_gicv5: Implement IRS_PE_{CR0, SELR, STATUSR}

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

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

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

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

hw/intc/arm_gicv5: Implement IRS_SPI_{SELR, STATUSR, CFGR, DOMAINR}

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

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

hw/intc/arm_gicv5: Implement gicv5_request_config()

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

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

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

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

hw/intc/arm_gicv5: Implement remaining set-config functions

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

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

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

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

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

hw/intc/arm_gicv5: Implement IRS_IST_{BASER, STATUSR, CFGR}

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

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

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

hw/intc/arm_gicv5: Add defines for GICv5 architected PPIs

The GICv5 defines architected numbers for the PPI sources like the
generic timer and the PMU; these are different from the ones
traditionally used by GICv2 and GICv3.  Add defines for them.

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-14-peter.maydell@linaro.org

hw/intc/arm_gicv5: Implement gicv5_class_name()

Implement a gicv5_class_name() function that does the same job as
gicv3_class_name(): allows board code to get the correct QOM type for
the GIC at runtime depending on whether KVM is enabled or not.

For the GICv5, we don't yet implement KVM support, so the KVM-enabled
codepath is always an error.

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-13-peter.maydell@linaro.org

hw/intc/arm_gicv5: Add link property for MemoryRegion for DMA

The GICv5 IRS keeps data structures in system memory.  (Notably, it
stores per-interrupt configuration information like the interrupt
priority and its active and pending state in an in-memory data
structure.) Add a link property so that the board or SoC can wire up
a MemoryRegion that we will do DMA to.  We name this property
"sysmem" to match the GICv3's equivalent property.

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-12-peter.maydell@linaro.org

hw/intc/arm_gicv5: Implement IRS ID regs

Implement the IRS frame ID registers IRS_IDR[0-7], IRS_IIDR and
IRS_AIDR.  These are all 32-bit registers.

We make these fields in the GIC state struct rather than just
hardcoding them in the register read function so that we can later
code "do this only if X is implemented" as a test on the ID register
value.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260327111700.795099-11-peter.maydell@linaro.org

hw/intc/arm_gicv5: Define macros for config frame registers

Define constants for the various registers in the IRS config frame
using the REG and FIELD macros.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-10-peter.maydell@linaro.org

hw/intc/arm_gicv5: Create inbound GPIO lines for SPIs

The GICv5 IRS may have inbound GPIO lines corresponding to SPIs
(shared peripheral interrupts).  Unlike the GICv3, it does not deal
with PPIs (private peripheral interrupts, i.e.  per-CPU interrupts):
in a GICv5 system those are handled entirely within the CPU
interface.  The inbound GPIO array is therefore a simple sequence of
one GPIO per SPI that this IRS handles.

Create the GPIO input array in gicv5_common_init_irqs_and_mmio().

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-9-peter.maydell@linaro.org

hw/intc/arm_gicv5: Create and validate QOM properties

Add code to the GICv5 skeleton which creates the QOM properties which
the board or SoC can use to configure the GIC, and the validation
code to check they are in range.  Generally these correspond to
fields in the IRS ID registers, and the properties are named
correspondingly.

Notable here is that unlike the GICv3 (which assumes its connected
CPUs are the system's CPUs starting from 0), we define a QOM array
property which is an array of pointers to the CPUs, and a QOM array
property which is an array of integers telling the GIC what the
IAFFID (interrupt affinity ID) for each CPU is; so a board or SoC
which wants to connect multiple CPUs to this GICv5 would do something
like:

    QList *cpulist = qlist_new(), *iaffidlist = qlist_new();

    for (int i = 0; i < ms->smp.cpus; i++) {
        qlist_append_link(cpulist, OBJECT(qemu_get_cpu(i)));
        qlist_append_int(iaffidlist, i);
    }
    qdev_prop_set_array(vms->gic, "cpus", cpulist);
    qdev_prop_set_array(vms->gic, "cpu-iaffids", iaffidlist);

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-8-peter.maydell@linaro.org

hw/intc/arm_gicv5: Add migration blocker

This initial version of the GICv5 will not support migration:

 * the spec is still only at EAC level, so the data to be
   migrated might in theory change before it is finalised
 * when we add support for missing features like EL2/EL3/Realm
   we might find we want to refactor the data structures we use
 * I still need to check against the proposed KVM GICv5
   handling to see if there are any awkward mismatches
   that might affect how we want to store the data
 * it's experimental, so for pragmatic reasons I'm skipping
   it to get the initial version done faster

Install a migration blocker to enforce this.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-7-peter.maydell@linaro.org

hw/intc/arm_gicv5: Implement skeleton code for IRS register frames

The GICv5 IRS has one mandatory register frame (the config frame) for
each of up to four supported physical interrupt domains.  Implement
the skeleton of the code needed to create these as sysbus MMIO
regions.

The config frame has a mix of 32-bit and 64-bit registers, and it is
valid to access the 64-bit registers with 32-bit accesses.  In a
similar way to the various GICv3 devices, we turn the MemoryRegionOps
read_with_attrs and write_with_attrs calls into calls on functions
specifically to read 32 or 64 bit values.  (We can't trivially
implement one in terms of the other because various registers have
side effects on write which must only trigger when the "correct" half
of the 64-bit register is written to.)

Unlike the GICv3, we choose to expose a sysbus MMIO region for each
interrupt domain even if the config of the GICv5 means that it
doesn't implement that domain.  This avoids having the config frame
for a domain ending up at a different MMIO region index depending on
the config of the GICv5.  (This matters more for GICv5 because it
supports Realm, and so there are more possible valid configurations.)

gicv5_common_init_irqs_and_mmio() does not yet create any IRQs, but
we name it this way to parallel the equivalent GICv3 function and to
avoid having to rename it when we add the IRQ line creation in a
subsequent commit.

The arm_gicv5_types.h header is a little undermotivated at this
point, but the aim is to have somewhere to put definitions that we
want in both the GIC proper and the CPU interface.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Message-id: 20260327111700.795099-6-peter.maydell@linaro.org

hw/arm/Kconfig: select ARM_GICV5 for ARM_VIRT board

When building the Arm "virt" board, pull in the GICv5.

We haven't added support for creating or wiring up the GICv5 in that
board yet, but adding it to the Kconfig early means that the GICv5
code will be compiled and so we can have more confidence that the
individual commits building it up are correct (or at least compile).

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-5-peter.maydell@linaro.org

hw/intc: Skeleton of GICv5 IRS classes

This commit adds the skeleton of the classes for the GICv5 IRS
(Interrupt Routing Service).  Since the IRS is the main (and only
non-optional) part of the GICv5 outside the CPU, we call it simply
"GICv5", in line with how we've handled the GICv3.

Since we're definitely going to need to have support for KVM VMs
where we present the guest with a GICv5, we use the same split
between an abstract "common" and a concrete specific-to-TCG child
class that we have for the various GICv3 components.  This avoids
having to refactor out the base class later.

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-4-peter.maydell@linaro.org

hw/core: Permit devices to define an array of link properties

Currently we allow devices to define "link properties" with
DEFINE_PROP_LINK(): these are a way to give a device a pointer to
another QOM object.  (Under the hood this is done by handing it the
canonical QOM path for the object.)

We also allow devices to define "array properties" with
DEFINE_PROP_ARRAY(): these are a way to give a device a
variable-length array of properties.

However, there is no way to define an array of link properties.  If
you try to do it by passing qdev_prop_link as the arrayprop argument
to DEFINE_PROP_ARRAY() you will get a crash because qdev_prop_link
does not provide the .set and .get methods in its PropertyInfo
struct.

This patch implements a new DEFINE_PROP_LINK_ARRAY(). In
a device you can use it like this:

struct MyDevice {
    ...
    uint32_t num_cpus;
    ARMCPU **cpus;
}

and in your Property array:
    DEFINE_PROP_LINK_ARRAY("cpus", MyDevice, num_cpus, cpus,
                           TYPE_ARM_CPU, ARMCPU *),

The array property code will fill in s->num_cpus, allocate memory in
s->cpus, and populate it with pointers.

On the device-creation side you set the property in the same way as
the existing array properties, using the new qlist_append_link()
function to append to the QList:

    QList *cpulist = qlist_new();
    for (int i = 0; i < cpus; i++) {
        qlist_append_link(cpulist, OBJECT(cpu[i]));
    }
    qdev_prop_set_array(mydev, "cpus", cpulist);

The implementation is mostly in the provision of the .set and
.get methods to the qdev_prop_link PropertyInfo struct. The
code of these methods parallels the code in
object_set_link_property() and object_get_link_property().  We can't
completely share the code with those functions because of differences
in where we get the information like the target QOM type, but I have
pulled out a new function object_resolve_and_typecheck() for the
shared "given a QOM path and a type, give me the object or an error"
code.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260327111700.795099-3-peter.maydell@linaro.org

qom/object: Add object_resolve_and_typecheck()

Add a new function object_resolve_and_typecheck(), whose purpose is
to look up the object at a given QOM path, confirm that it is the
expected type, and return it.  This is similar to the existing
object_resolve_path_type(), but it insists on a non-ambiguous path.

We were already using this functionality internally to object.c as
part of the object_resolve_link() function, so this patch implements
the new function by pulling the link-property specific parts out of
the more generic resolve-and-typecheck part.

The motivation for this function is that we want to allow devices to
provide an array of link properties; for that we will need to be able
to provide the expected type of the linked object in a different way
to the single-item link properties.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260327111700.795099-2-peter.maydell@linaro.org

bsd-user: Add call to do_bsd_ioctl and add bsd-ioctl.c to the build

Finally, connect do_bsd_ioctl to the build. Call bsd_ioctl_init() from
syscall_init()

Signed-off-by: Stacey Son <sson@FreeBSD.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Warner Losh <imp@bsdimp.com>

bsd-user: Add init_bsd_ioctl function

Add initialization function that registers thunk structures and
patches ioctl table entries with correct size parameters for
target architecture.

Signed-off-by: Stacey Son <sson@FreeBSD.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Warner Losh <imp@bsdimp.com>

bsd-user: Add do_bsd_ioctl main function

Add main ioctl emulation dispatcher that handles table-driven
ioctl translation with thunk-based structure conversion. Supports
TYPE_NULL, TYPE_INT, and TYPE_PTR argument types with read, write,
and read-write access modes.

Signed-off-by: Stacey Son <sson@FreeBSD.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Warner Losh <imp@bsdimp.com>

bsd-user: Add do_ioctl_in6_ifreq_sockaddr_int function

Add special handler for IPv6 interface request ioctls that take
a sockaddr_in6 structure as input and return an integer flag value,
such as SIOCGIFAFLAG_IN6 and SIOCGIFALIFETIME_IN6.

Signed-off-by: Stacey Son <sson@FreeBSD.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Warner Losh <imp@bsdimp.com>

bsd-user: Add target_to_host_sockaddr_in6 function

Add helper function to convert target IPv6 socket address structure
to host format, handling all sockaddr_in6 fields including address,
port, flow info, and scope ID.

Signed-off-by: Stacey Son <sson@FreeBSD.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Warner Losh <imp@bsdimp.com>