qemu-commits
[Top][All Lists]
Advanced

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

[Qemu-commits] [qemu/qemu] 4a0245: target/arm: Remove redundant scaling


From: Peter Maydell
Subject: [Qemu-commits] [qemu/qemu] 4a0245: target/arm: Remove redundant scaling of nexttick
Date: Mon, 06 Jan 2020 02:45:16 -0800

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 4a0245b62502ee9ca7774712de4bb05d9bf47152
      
https://github.com/qemu/qemu/commit/4a0245b62502ee9ca7774712de4bb05d9bf47152
  Author: Andrew Jeffery <address@hidden>
  Date:   2019-12-20 (Fri, 20 Dec 2019)

  Changed paths:
    M target/arm/helper.c

  Log Message:
  -----------
  target/arm: Remove redundant scaling of nexttick

The corner-case codepath was adjusting nexttick such that overflow
wouldn't occur when timer_mod() scaled the value back up. Remove a use
of GTIMER_SCALE and avoid unnecessary operations by calling
timer_mod_ns() directly.

Signed-off-by: Andrew Jeffery <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Reviewed-by: Cédric Le Goater <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 7def87548272f6f3831c7ae5ba713c5ccbd5d547
      
https://github.com/qemu/qemu/commit/7def87548272f6f3831c7ae5ba713c5ccbd5d547
  Author: Andrew Jeffery <address@hidden>
  Date:   2019-12-20 (Fri, 20 Dec 2019)

  Changed paths:
    M target/arm/cpu.c
    M target/arm/cpu.h
    M target/arm/helper.c

  Log Message:
  -----------
  target/arm: Abstract the generic timer frequency

Prepare for SoCs such as the ASPEED AST2600 whose firmware configures
CNTFRQ to values significantly larger than the static 62.5MHz value
currently derived from GTIMER_SCALE. As the OS potentially derives its
timer periods from the CNTFRQ value the lack of support for running
QEMUTimers at the appropriate rate leads to sticky behaviour in the
guest.

Substitute the GTIMER_SCALE constant with use of a helper to derive the
period from gt_cntfrq_hz stored in struct ARMCPU. Initially set
gt_cntfrq_hz to the frequency associated with GTIMER_SCALE so current
behaviour is maintained.

Signed-off-by: Andrew Jeffery <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 96eec6b2b389215f43d7f07e823cb196f9185052
      
https://github.com/qemu/qemu/commit/96eec6b2b389215f43d7f07e823cb196f9185052
  Author: Andrew Jeffery <address@hidden>
  Date:   2019-12-20 (Fri, 20 Dec 2019)

  Changed paths:
    M target/arm/cpu.c
    M target/arm/helper.c

  Log Message:
  -----------
  target/arm: Prepare generic timer for per-platform CNTFRQ

The ASPEED AST2600 clocks the generic timer at the rate of HPLL. On
recent firmwares this is at 1125MHz, which is considerably quicker than
the assumed 62.5MHz of the current generic timer implementation. The
delta between the value as read from CNTFRQ and the true rate of the
underlying QEMUTimer leads to sticky behaviour in AST2600 guests.

Add a feature-gated property exposing CNTFRQ for ARM CPUs providing the
generic timer. This allows platforms to configure CNTFRQ (and the
associated QEMUTimer) to the appropriate frequency prior to starting the
guest.

As the platform can now determine the rate of CNTFRQ we're exposed to
limitations of QEMUTimer that didn't previously materialise: In the
course of emulation we need to arbitrarily and accurately convert
between guest ticks and time, but we're constrained by QEMUTimer's use
of an integer scaling factor. The effect is QEMUTimer cannot exactly
capture the period of frequencies that do not cleanly divide
NANOSECONDS_PER_SECOND for scaling ticks to time. As such, provide an
equally inaccurate scaling factor for scaling time to ticks so at least
a self-consistent inverse relationship holds.

Signed-off-by: Andrew Jeffery <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 058d095532dbd50aa3a2b5ef907b76c08f7d6de7
      
https://github.com/qemu/qemu/commit/058d095532dbd50aa3a2b5ef907b76c08f7d6de7
  Author: Andrew Jeffery <address@hidden>
  Date:   2019-12-20 (Fri, 20 Dec 2019)

  Changed paths:
    M hw/arm/aspeed_ast2600.c

  Log Message:
  -----------
  ast2600: Configure CNTFRQ at 1125MHz

This matches the configuration set by u-boot on the AST2600.

Signed-off-by: Andrew Jeffery <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Reviewed-by: Cédric Le Goater <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 3d44c60500785f18bb469c9de0aeba7415c0f28f
      
https://github.com/qemu/qemu/commit/3d44c60500785f18bb469c9de0aeba7415c0f28f
  Author: Simon Veith <address@hidden>
  Date:   2019-12-20 (Fri, 20 Dec 2019)

  Changed paths:
    M hw/arm/smmuv3.c

  Log Message:
  -----------
  hw/arm/smmuv3: Apply address mask to linear strtab base address

In the SMMU_STRTAB_BASE register, the stream table base address only
occupies bits [51:6]. Other bits, such as RA (bit [62]), must be masked
out to obtain the base address.

The branch for 2-level stream tables correctly applies this mask by way
of SMMU_BASE_ADDR_MASK, but the one for linear stream tables does not.

Apply the missing mask in that case as well so that the correct stream
base address is used by guests which configure a linear stream table.

Linux guests are unaffected by this change because they choose a 2-level
stream table layout for the QEMU SMMUv3, based on the size of its stream
ID space.

ref. ARM IHI 0070C, section 6.3.23.

Signed-off-by: Simon Veith <address@hidden>
Acked-by: Eric Auger <address@hidden>
Tested-by: Eric Auger <address@hidden>
Message-id: address@hidden
Cc: Eric Auger <address@hidden>
Cc: address@hidden
Cc: address@hidden
Acked-by: Eric Auger <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 3293b9f514a413e019b7dbc9d543458075b4849e
      
https://github.com/qemu/qemu/commit/3293b9f514a413e019b7dbc9d543458075b4849e
  Author: Simon Veith <address@hidden>
  Date:   2019-12-20 (Fri, 20 Dec 2019)

  Changed paths:
    M hw/arm/smmuv3-internal.h

  Log Message:
  -----------
  hw/arm/smmuv3: Correct SMMU_BASE_ADDR_MASK value

There are two issues with the current value of SMMU_BASE_ADDR_MASK:

- At the lower end, we are clearing bits [4:0]. Per the SMMUv3 spec,
  we should also be treating bit 5 as zero in the base address.
- At the upper end, we are clearing bits [63:48]. Per the SMMUv3 spec,
  only bits [63:52] must be explicitly treated as zero.

Update the SMMU_BASE_ADDR_MASK value to mask out bits [63:52] and [5:0].

ref. ARM IHI 0070C, section 6.3.23.

Signed-off-by: Simon Veith <address@hidden>
Acked-by: Eric Auger <address@hidden>
Tested-by: Eric Auger <address@hidden>
Message-id: address@hidden
Cc: Eric Auger <address@hidden>
Cc: address@hidden
Cc: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 05ff2fb80ce4ca85d8a39d48ff8156de739b4f51
      
https://github.com/qemu/qemu/commit/05ff2fb80ce4ca85d8a39d48ff8156de739b4f51
  Author: Simon Veith <address@hidden>
  Date:   2019-12-20 (Fri, 20 Dec 2019)

  Changed paths:
    M hw/arm/smmuv3.c

  Log Message:
  -----------
  hw/arm/smmuv3: Check stream IDs against actual table LOG2SIZE

When checking whether a stream ID is in range of the stream table, we
have so far been only checking it against our implementation limit
(SMMU_IDR1_SIDSIZE). However, the guest can program the
STRTAB_BASE_CFG.LOG2SIZE field to a size that is smaller than this
limit.

Check the stream ID against this limit as well to match the hardware
behavior of raising C_BAD_STREAMID events in case the limit is exceeded.
Also, ensure that we do not go one entry beyond the end of the table by
checking that its index is strictly smaller than the table size.

ref. ARM IHI 0070C, section 6.3.24.

Signed-off-by: Simon Veith <address@hidden>
Acked-by: Eric Auger <address@hidden>
Tested-by: Eric Auger <address@hidden>
Message-id: address@hidden
Cc: Eric Auger <address@hidden>
Cc: address@hidden
Cc: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 41678c33aac61261522b74f08595ccf2221a430a
      
https://github.com/qemu/qemu/commit/41678c33aac61261522b74f08595ccf2221a430a
  Author: Simon Veith <address@hidden>
  Date:   2019-12-20 (Fri, 20 Dec 2019)

  Changed paths:
    M hw/arm/smmuv3.c

  Log Message:
  -----------
  hw/arm/smmuv3: Align stream table base address to table size

Per the specification, and as observed in hardware, the SMMUv3 aligns
the SMMU_STRTAB_BASE address to the size of the table by masking out the
respective least significant bits in the ADDR field.

Apply this masking logic to our smmu_find_ste() lookup function per the
specification.

ref. ARM IHI 0070C, section 6.3.23.

Signed-off-by: Simon Veith <address@hidden>
Acked-by: Eric Auger <address@hidden>
Tested-by: Eric Auger <address@hidden>
Message-id: address@hidden
Cc: Eric Auger <address@hidden>
Cc: address@hidden
Cc: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: a7f65ceb851af5a5b639c6e30801076d848db2c2
      
https://github.com/qemu/qemu/commit/a7f65ceb851af5a5b639c6e30801076d848db2c2
  Author: Simon Veith <address@hidden>
  Date:   2019-12-20 (Fri, 20 Dec 2019)

  Changed paths:
    M hw/arm/smmuv3-internal.h

  Log Message:
  -----------
  hw/arm/smmuv3: Use correct bit positions in EVT_SET_ADDR2 macro

The bit offsets in the EVT_SET_ADDR2 macro do not match those specified
in the ARM SMMUv3 Architecture Specification. In all events that use
this macro, e.g. F_WALK_EABT, the faulting fetch address or IPA actually
occupies the 32-bit words 6 and 7 in the event record contiguously, with
the upper and lower unused bits clear due to alignment or maximum
supported address bits. How many bits are clear depends on the
individual event type.

Update the macro to write to the correct words in the event record so
that guest drivers can obtain accurate address information on events.

ref. ARM IHI 0070C, sections 7.3.12 through 7.3.16.

Signed-off-by: Simon Veith <address@hidden>
Acked-by: Eric Auger <address@hidden>
Tested-by: Eric Auger <address@hidden>
Message-id: address@hidden
Cc: Eric Auger <address@hidden>
Cc: address@hidden
Cc: address@hidden
Acked-by: Eric Auger <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: b255cafb59578d16716186ed955717bc8f87bdb7
      
https://github.com/qemu/qemu/commit/b255cafb59578d16716186ed955717bc8f87bdb7
  Author: Simon Veith <address@hidden>
  Date:   2019-12-20 (Fri, 20 Dec 2019)

  Changed paths:
    M hw/arm/smmuv3.c

  Log Message:
  -----------
  hw/arm/smmuv3: Report F_STE_FETCH fault address in correct word position

The smmuv3_record_event() function that generates the F_STE_FETCH error
uses the EVT_SET_ADDR macro to record the fetch address, placing it in
32-bit words 4 and 5.

The correct position for this address is in words 6 and 7, per the
SMMUv3 Architecture Specification.

Update the function to use the EVT_SET_ADDR2 macro instead, which is the
macro intended for writing to these words.

ref. ARM IHI 0070C, section 7.3.4.

Signed-off-by: Simon Veith <address@hidden>
Acked-by: Eric Auger <address@hidden>
Tested-by: Eric Auger <address@hidden>
Message-id: address@hidden
Cc: Eric Auger <address@hidden>
Cc: address@hidden
Cc: address@hidden
Acked-by: Eric Auger <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 0ee8b24a69e410ce5abdc30b7050dc9e26a647ca
      
https://github.com/qemu/qemu/commit/0ee8b24a69e410ce5abdc30b7050dc9e26a647ca
  Author: Philippe Mathieu-Daudé <address@hidden>
  Date:   2019-12-20 (Fri, 20 Dec 2019)

  Changed paths:
    M target/arm/helper.c

  Log Message:
  -----------
  target/arm: Display helpful message when hflags mismatch

Instead of crashing in a confuse way, give some hint to the user
about why we aborted. He might report the issue without having
to use a debugger.

Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Reviewed-by: Richard Henderson <address@hidden>
Tested-by: Niek Linnenbank <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: c8fa6079eb35888587f1be27c1590da4edcc5098
      
https://github.com/qemu/qemu/commit/c8fa6079eb35888587f1be27c1590da4edcc5098
  Author: Niek Linnenbank <address@hidden>
  Date:   2019-12-20 (Fri, 20 Dec 2019)

  Changed paths:
    M target/arm/arm-powerctl.c

  Log Message:
  -----------
  arm/arm-powerctl: rebuild hflags after setting CP15 bits in arm_set_cpu_on()

After setting CP15 bits in arm_set_cpu_on() the cached hflags must
be rebuild to reflect the changed processor state. Without rebuilding,
the cached hflags would be inconsistent until the next call to
arm_rebuild_hflags(). When QEMU is compiled with debugging enabled
(--enable-debug), this problem is captured shortly after the first
call to arm_set_cpu_on() for CPUs running in ARM 32-bit non-secure mode:

  qemu-system-arm: target/arm/helper.c:11359: cpu_get_tb_cpu_state:
  Assertion `flags == rebuild_hflags_internal(env)' failed.
  Aborted (core dumped)

Fixes: 0c7f8c43daf65
Cc: address@hidden
Signed-off-by: Niek Linnenbank <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: f17783e706ab9c7b3a2b69cf48e4f0ba40664f54
      
https://github.com/qemu/qemu/commit/f17783e706ab9c7b3a2b69cf48e4f0ba40664f54
  Author: Peter Maydell <address@hidden>
  Date:   2020-01-03 (Fri, 03 Jan 2020)

  Changed paths:
    M hw/arm/aspeed_ast2600.c
    M hw/arm/smmuv3-internal.h
    M hw/arm/smmuv3.c
    M target/arm/arm-powerctl.c
    M target/arm/cpu.c
    M target/arm/cpu.h
    M target/arm/helper.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20191220' 
into staging

target-arm queue:
 * Support emulating the generic timers at frequencies other than 62.5MHz
 * Various fixes for SMMUv3 emulation bugs
 * Improve assert error message for hflags mismatches
 * arm-powerctl: rebuild hflags after setting CP15 bits in arm_set_cpu_on()

# gpg: Signature made Fri 20 Dec 2019 14:25:51 GMT
# gpg:                using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg:                issuer "address@hidden"
# gpg: Good signature from "Peter Maydell <address@hidden>" [ultimate]
# gpg:                 aka "Peter Maydell <address@hidden>" [ultimate]
# gpg:                 aka "Peter Maydell <address@hidden>" [ultimate]
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83  15CF 3C25 25ED 1436 0CDE

* remotes/pmaydell/tags/pull-target-arm-20191220:
  arm/arm-powerctl: rebuild hflags after setting CP15 bits in arm_set_cpu_on()
  target/arm: Display helpful message when hflags mismatch
  hw/arm/smmuv3: Report F_STE_FETCH fault address in correct word position
  hw/arm/smmuv3: Use correct bit positions in EVT_SET_ADDR2 macro
  hw/arm/smmuv3: Align stream table base address to table size
  hw/arm/smmuv3: Check stream IDs against actual table LOG2SIZE
  hw/arm/smmuv3: Correct SMMU_BASE_ADDR_MASK value
  hw/arm/smmuv3: Apply address mask to linear strtab base address
  ast2600: Configure CNTFRQ at 1125MHz
  target/arm: Prepare generic timer for per-platform CNTFRQ
  target/arm: Abstract the generic timer frequency
  target/arm: Remove redundant scaling of nexttick

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/f0dcfddecee8...f17783e706ab



reply via email to

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