Skip to content
Snippets Groups Projects
Select Git revision
  • feature/libtcg-rebase default protected
1 result
Search by author
  • Any Author
  • Anton Anton anjo
1 author
  1. May 26, 2022
  3. May 25, 2022
  5. May 24, 2022
  7. May 23, 2022
  9. May 19, 2022
    • Richard Henderson's avatar
      target/arm: Use FIELD definitions for CPACR, CPTR_ELx · fab8ad39
      Richard Henderson authored 
      
We had a few CPTR_* bits defined, but missed quite a few.
Complete all of the fields up to ARMv9.2.
Use FIELD_EX64 instead of manual extract32.

Reviewed-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Message-id: 20220517054850.177016-3-richard.henderson@linaro.org
Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      fab8ad39
    • Peter Maydell's avatar
      ptimer: Rename PTIMER_POLICY_DEFAULT to PTIMER_POLICY_LEGACY · 9598c1bb
      Peter Maydell authored 
      
The traditional ptimer behaviour includes a collection of weird edge
case behaviours.  In 2016 we improved the ptimer implementation to
fix these and generally make the behaviour more flexible, with
ptimers opting in to the new behaviour by passing an appropriate set
of policy flags to ptimer_init().  For backwards-compatibility, we
defined PTIMER_POLICY_DEFAULT (which sets no flags) to give the old
weird behaviour.

This turns out to be a poor choice of name, because people writing
new devices which use ptimers are misled into thinking that the
default is probably a sensible choice of flags, when in fact it is
almost always not what you want.  Rename PTIMER_POLICY_DEFAULT to
PTIMER_POLICY_LEGACY and beef up the comment to more clearly say that
new devices should not be using it.

The code-change part of this commit was produced by
  sed -i -e 's/PTIMER_POLICY_DEFAULT/PTIMER_POLICY_LEGACY/g' $(git grep -l PTIMER_POLICY_DEFAULT)
with the exception of a test name string change in
tests/unit/ptimer-test.c which was added manually.

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: default avatarFrancisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Message-id: 20220516103058.162280-1-peter.maydell@linaro.org
      9598c1bb
    • Peter Maydell's avatar
      hw/arm/virt: Drop #size-cells and #address-cells from gpio-keys dtb node · afdcbddc
      Peter Maydell authored 
      
The virt board generates a gpio-keys node in the dtb, but it
incorrectly gives this node #size-cells and #address-cells
properties. If you dump the dtb with 'machine dumpdtb=file.dtb'
and run it through dtc, dtc will warn about this:

Warning (avoid_unnecessary_addr_size): /gpio-keys: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property

Remove the bogus properties.

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Message-id: 20220513131316.4081539-3-peter.maydell@linaro.org
      afdcbddc
    • Peter Maydell's avatar
      hw/arm/virt: Fix incorrect non-secure flash dtb node name · e8ca920f
      Peter Maydell authored 
      
In the virt board with secure=on we put two nodes in the dtb
for flash devices: one for the secure-only flash, and one
for the non-secure flash. We get the reg properties for these
correct, but in the DT node name, which by convention includes
the base address of devices, we used the wrong address. Fix it.

Spotted by dtc, which will complain
Warning (unique_unit_address): /flash@0: duplicate unit-address (also used in node /secflash@0)
if you dump the dtb from QEMU with -machine dumpdtb=file.dtb
and then decompile it with dtc.

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Message-id: 20220513131316.4081539-2-peter.maydell@linaro.org
      e8ca920f
    • Philippe Mathieu-Daudé's avatar
      hw/adc/zynq-xadc: Use qemu_irq typedef · 6e76d35f
      Philippe Mathieu-Daudé authored 
      
Except hw/core/irq.c which implements the forward-declared opaque
qemu_irq structure, hw/adc/zynq-xadc.{c,h} are the only files not
using the typedef. Fix this single exception.

Signed-off-by: default avatarPhilippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: default avatarBernhard Beschow <shentey@gmail.com>
Message-id: 20220509202035.50335-1-philippe.mathieu.daude@gmail.com
Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      6e76d35f
    • Peter Maydell's avatar
      hw/intc/arm_gicv3: Provide ich_num_aprs() · 5d55f827
      Peter Maydell authored 
      
We previously open-coded the expression for the number of virtual APR
registers and the assertion that it was not going to cause us to
overflow the cs->ich_apr[] array.  Factor this out into a new
ich_num_aprs() function, for consistency with the icc_num_aprs()
function we just added for the physical APR handling.

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Message-id: 20220512151457.3899052-7-peter.maydell@linaro.org
Message-id: 20220506162129.2896966-6-peter.maydell@linaro.org
      5d55f827
    • Peter Maydell's avatar
      hw/intc/arm_gicv3: Use correct number of priority bits for the CPU · 39f29e59
      Peter Maydell authored 
      
Make the GICv3 set its number of bits of physical priority from the
implementation-specific value provided in the CPU state struct, in
the same way we already do for virtual priority bits.  Because this
would be a migration compatibility break, we provide a property
force-8-bit-prio which is enabled for 7.0 and earlier versioned board
models to retain the legacy "always use 8 bits" behaviour.

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Message-id: 20220512151457.3899052-6-peter.maydell@linaro.org
Message-id: 20220506162129.2896966-5-peter.maydell@linaro.org
      39f29e59
    • Peter Maydell's avatar
      hw/intc/arm_gicv3: Support configurable number of physical priority bits · 84597ff3
      Peter Maydell authored 
      
The GICv3 code has always supported a configurable number of virtual
priority and preemption bits, but our implementation currently
hardcodes the number of physical priority bits at 8.  This is not
what most hardware implementations provide; for instance the
Cortex-A53 provides only 5 bits of physical priority.

Make the number of physical priority/preemption bits driven by fields
in the GICv3CPUState, the way that we already do for virtual
priority/preemption bits.  We set cs->pribits to 8, so there is no
behavioural change in this commit.  A following commit will add the
machinery for CPUs to set this to the correct value for their
implementation.

Note that changing the number of priority bits would be a migration
compatibility break, because the semantics of the icc_apr[][] array
changes.

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Message-id: 20220512151457.3899052-5-peter.maydell@linaro.org
Message-id: 20220506162129.2896966-4-peter.maydell@linaro.org
      84597ff3
    • Peter Maydell's avatar
      hw/intc/arm_gicv3_kvm.c: Stop using GIC_MIN_BPR constant · 9774c0f7
      Peter Maydell authored 
      
The GIC_MIN_BPR constant defines the minimum BPR value that the TCG
emulated GICv3 supports.  We're currently using this also as the
value we reset the KVM GICv3 ICC_BPR registers to, but this is only
right by accident.

We want to make the emulated GICv3 use a configurable number of
priority bits, which means that GIC_MIN_BPR will no longer be a
constant.  Replace the uses in the KVM reset code with literal 0,
plus a constant explaining why this is reasonable.

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Message-id: 20220512151457.3899052-4-peter.maydell@linaro.org
Message-id: 20220506162129.2896966-3-peter.maydell@linaro.org
      9774c0f7
    • Peter Maydell's avatar
      hw/intc/arm_gicv3: report correct PRIbits field in ICV_CTLR_EL1 · 9c6f933e
      Peter Maydell authored 
      
As noted in the comment, the PRIbits field in ICV_CTLR_EL1 is
supposed to match the ICH_VTR_EL2 PRIbits setting; that is, it is the
virtual priority bit setting, not the physical priority bit setting.
(For QEMU currently we always implement 8 bits of physical priority,
so the PRIbits field was previously 7, since it is defined to be
"priority bits - 1".)

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Message-id: 20220512151457.3899052-3-peter.maydell@linaro.org
Message-id: 20220506162129.2896966-2-peter.maydell@linaro.org
      9c6f933e
    • Peter Maydell's avatar
      hw/intc/arm_gicv3_cpuif: Handle CPUs that don't specify GICv3 parameters · 272f75e8
      Peter Maydell authored 
      
We allow a GICv3 to be connected to any CPU, but we don't do anything
to handle the case where the CPU type doesn't in hardware have a
GICv3 CPU interface and so the various GIC configuration fields
(gic_num_lrs, vprebits, vpribits) are not specified.

The current behaviour is that we will add the EL1 CPU interface
registers, but will not put in the EL2 CPU interface registers, even
if the CPU has EL2, which will leave the GIC in a broken state and
probably result in the guest crashing as it tries to set it up.  This
only affects the virt board when using the cortex-a15 or cortex-a7
CPU types (both 32-bit) with -machine gic-version=3 (or 'max')
and -machine virtualization=on.

Instead of failing to set up the EL2 registers, if the CPU doesn't
define the GIC configuration set it to a reasonable default, matching
the standard configuration for most Arm CPUs.

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Message-id: 20220512151457.3899052-2-peter.maydell@linaro.org
      272f75e8