qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH v2 0/6] gicv3: Use right number of prio bits for the CPU


From: Peter Maydell
Subject: [PATCH v2 0/6] gicv3: Use right number of prio bits for the CPU
Date: Thu, 12 May 2022 16:14:51 +0100

This patchset fills in an odd inconsistency in our GICv3 emulation
that I noticed while I was doing the GICv4 work.  At the moment we
allow the CPU to specify the number of bits of virtual priority (via
the ARMCPU::gic_vpribits field), but we always use 8 bits of physical
priority, even though to my knowledge no real Arm CPU hardware has
that many.

This series makes the GICv3 emulation use a runtime-configurable
number of physical priority bits, and sets it to match the number
used by the various CPUs we implement (which is 5 for all the
Cortex-Axx CPUs we emulate).  Because changing the number of priority
bits is a migration compatibility break, we use a compat property to
keep the number of priority bits at 8 for older versions of the virt
board.

The main change in version 2 fixes a failure in 'make check'
(oops...) by stopping the GICv3 from asserting when used with CPUs
which don't specify the various priority bit values.  In practice
that means one of the 32-bit CPUs which in real hardware don't have a
GICv3.  The fix is to use a set of sensible default values if the CPU
doesn't specify.  The other approach would be to make the GIC fail
realize if the CPU type doesn't officially have a GICv3 interface,
and make the virt board check for mismatches and handle 'gic-version'
accordingly, but this seems like less effort.  I don't think
anybody's likely using this corner case anyway: the only reason I ran
into it is that with my patches to add cpu->gic_prebits one of the
tests in 'make check' now runs into it because it unintentionally and
unnecessarily asks for gicv3 and cortex-a15.

The new patch 1 implements that "use default values" logic for the
existing gic_num_lrs/gic_vpribits/gic_vprebits, fixing a bug where
the combination of GICv3 + 32-bit CPU + EL2 would cause us to
register the EL1 GICv3 sysregs but not the EL2 sysregs, probably
causing a guest crash.  Patch 5 then gains the minor tweak to make
the new gic_pribits follow suit.

Changes v1->v2:
 * new patch 1, as above
 * patch 5: drop TODO comment about a64fx
 * patch 5: add settings for cortex-a76, neoverse-n1
 * patch 5: default pribits to 5 if CPU doesn't set it
 * patch 6: retain local variable for loop bound

Patches 2-6 have been reviewed.

thanks
-- PMM

Peter Maydell (6):
  hw/intc/arm_gicv3_cpuif: Handle CPUs that don't specify GICv3
    parameters
  hw/intc/arm_gicv3: report correct PRIbits field in ICV_CTLR_EL1
  hw/intc/arm_gicv3_kvm.c: Stop using GIC_MIN_BPR constant
  hw/intc/arm_gicv3: Support configurable number of physical priority
    bits
  hw/intc/arm_gicv3: Use correct number of priority bits for the CPU
  hw/intc/arm_gicv3: Provide ich_num_aprs()

 include/hw/intc/arm_gicv3_common.h |   8 +-
 target/arm/cpu.h                   |   1 +
 hw/core/machine.c                  |   4 +-
 hw/intc/arm_gicv3_common.c         |   5 +
 hw/intc/arm_gicv3_cpuif.c          | 225 ++++++++++++++++++++---------
 hw/intc/arm_gicv3_kvm.c            |  16 +-
 target/arm/cpu64.c                 |   6 +
 7 files changed, 190 insertions(+), 75 deletions(-)

-- 
2.25.1




reply via email to

[Prev in Thread] Current Thread [Next in Thread]