[Qemu-commits] [qemu/qemu] 45b1a2: target/arm: report ARMv8-A FP support for AArch32 ...

[Peter Maydell]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 45b1a243b81a7c9ae56235937280711dd9914ca7
      
https://github.com/qemu/qemu/commit/45b1a243b81a7c9ae56235937280711dd9914ca7
  Author: Alex Bennée <address@hidden>
  Date:   2019-07-15 (Mon, 15 Jul 2019)

  Changed paths:
    M target/arm/cpu.c

  Log Message:
  -----------
  target/arm: report ARMv8-A FP support for AArch32 -cpu max

When we converted to using feature bits in 602f6e42cfbf we missed out
the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for
-cpu max configurations. This caused a regression in the GCC test
suite. Fix this by setting the appropriate bits in mvfr1.FPHP to
report ARMv8-A with FP support (but not ARMv8.2-FP16).

Fixes: https://bugs.launchpad.net/qemu/+bug/1836078
Signed-off-by: Alex Bennée <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 5937bd50d3841b6ab2592c1ff4233448762a8483
      
https://github.com/qemu/qemu/commit/5937bd50d3841b6ab2592c1ff4233448762a8483
  Author: Philippe Mathieu-Daudé <address@hidden>
  Date:   2019-07-15 (Mon, 15 Jul 2019)

  Changed paths:
    M hw/ssi/xilinx_spips.c

  Log Message:
  -----------
  hw/ssi/xilinx_spips: Convert lqspi_read() to read_with_attrs

In the next commit we will implement the write_with_attrs()
handler. To avoid using different APIs, convert the read()
handler first.

Reviewed-by: Francisco Iglesias <address@hidden>
Tested-by: Francisco Iglesias <address@hidden>
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 936a236c4e4b1068ade99220260cd04f68eb0212
      
https://github.com/qemu/qemu/commit/936a236c4e4b1068ade99220260cd04f68eb0212
  Author: Philippe Mathieu-Daudé <address@hidden>
  Date:   2019-07-15 (Mon, 15 Jul 2019)

  Changed paths:
    M hw/ssi/xilinx_spips.c

  Log Message:
  -----------
  hw/ssi/xilinx_spips: Avoid AXI writes to the LQSPI linear memory

Lei Sun found while auditing the code that a CPU write would
trigger a NULL pointer dereference.

>From UG1085 datasheet [*] AXI writes in this region are ignored
and generates an AXI Slave Error (SLVERR).

Fix by implementing the write_with_attrs() handler.
Return MEMTX_ERROR when the region is accessed (this error maps
to an AXI slave error).

[*] 
https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf

Reported-by: Lei Sun <address@hidden>
Reviewed-by: Francisco Iglesias <address@hidden>
Tested-by: Francisco Iglesias <address@hidden>
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 526668c734e6a07f2fedfd378840a61b70c1cbab
      
https://github.com/qemu/qemu/commit/526668c734e6a07f2fedfd378840a61b70c1cbab
  Author: Philippe Mathieu-Daudé <address@hidden>
  Date:   2019-07-15 (Mon, 15 Jul 2019)

  Changed paths:
    M hw/ssi/xilinx_spips.c

  Log Message:
  -----------
  hw/ssi/xilinx_spips: Avoid out-of-bound access to lqspi_buf[]

Both lqspi_read() and lqspi_load_cache() expect a 32-bit
aligned address.

>From UG1085 datasheet [*] chapter on 'Quad-SPI Controller':

  Transfer Size Limitations

    Because of the 32-bit wide TX, RX, and generic FIFO, all
    APB/AXI transfers must be an integer multiple of 4-bytes.
    Shorter transfers are not possible.

Set MemoryRegionOps.impl values to force 32-bit accesses,
this way we are sure we do not access the lqspi_buf[] array
out of bound.

[*] 
https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf

Reviewed-by: Francisco Iglesias <address@hidden>
Tested-by: Francisco Iglesias <address@hidden>
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: c0bccee9b40ec58c9d165b406ae3d4f63652ce53
      
https://github.com/qemu/qemu/commit/c0bccee9b40ec58c9d165b406ae3d4f63652ce53
  Author: Philippe Mathieu-Daudé <address@hidden>
  Date:   2019-07-15 (Mon, 15 Jul 2019)

  Changed paths:
    M hw/ssi/mss-spi.c

  Log Message:
  -----------
  hw/ssi/mss-spi: Avoid crash when reading empty RX FIFO

Reading the RX_DATA register when the RX_FIFO is empty triggers
an abort. This can be easily reproduced:

  $ qemu-system-arm -M emcraft-sf2 -monitor stdio -S
  QEMU 4.0.50 monitor - type 'help' for more information
  (qemu) x 0x40001010
  Aborted (core dumped)

  (gdb) bt
  #1  0x00007f035874f895 in abort () at /lib64/libc.so.6
  #2  0x00005628686591ff in fifo8_pop (fifo=0x56286a9a4c68) at util/fifo8.c:66
  #3  0x00005628683e0b8e in fifo32_pop (fifo=0x56286a9a4c68) at 
include/qemu/fifo32.h:137
  #4  0x00005628683e0efb in spi_read (opaque=0x56286a9a4850, addr=4, size=4) at 
hw/ssi/mss-spi.c:168
  #5  0x0000562867f96801 in memory_region_read_accessor (mr=0x56286a9a4b60, 
addr=16, value=0x7ffeecb0c5c8, size=4, shift=0, mask=4294967295, attrs=...) at 
memory.c:439
  #6  0x0000562867f96cdb in access_with_adjusted_size (addr=16, 
value=0x7ffeecb0c5c8, size=4, access_size_min=1, access_size_max=4, 
access_fn=0x562867f967c3 <memory_region_read_accessor>, mr=0x56286a9a4b60, 
attrs=...) at memory.c:569
  #7  0x0000562867f99940 in memory_region_dispatch_read1 (mr=0x56286a9a4b60, 
addr=16, pval=0x7ffeecb0c5c8, size=4, attrs=...) at memory.c:1420
  #8  0x0000562867f99a08 in memory_region_dispatch_read (mr=0x56286a9a4b60, 
addr=16, pval=0x7ffeecb0c5c8, size=4, attrs=...) at memory.c:1447
  #9  0x0000562867f38721 in flatview_read_continue (fv=0x56286aec6360, 
addr=1073745936, attrs=..., buf=0x7ffeecb0c7c0 "\340ǰ\354\376\177", len=4, 
addr1=16, l=4, mr=0x56286a9a4b60) at exec.c:3385
  #10 0x0000562867f38874 in flatview_read (fv=0x56286aec6360, addr=1073745936, 
attrs=..., buf=0x7ffeecb0c7c0 "\340ǰ\354\376\177", len=4) at exec.c:3423
  #11 0x0000562867f388ea in address_space_read_full (as=0x56286aa3e890, 
addr=1073745936, attrs=..., buf=0x7ffeecb0c7c0 "\340ǰ\354\376\177", len=4) at 
exec.c:3436
  #12 0x0000562867f389c5 in address_space_rw (as=0x56286aa3e890, 
addr=1073745936, attrs=..., buf=0x7ffeecb0c7c0 "\340ǰ\354\376\177", len=4, 
is_write=false) at exec.c:3466
  #13 0x0000562867f3bdd7 in cpu_memory_rw_debug (cpu=0x56286aa19d00, 
addr=1073745936, buf=0x7ffeecb0c7c0 "\340ǰ\354\376\177", len=4, is_write=0) at 
exec.c:3976
  #14 0x000056286811ed51 in memory_dump (mon=0x56286a8c32d0, count=1, 
format=120, wsize=4, addr=1073745936, is_physical=0) at monitor/misc.c:730
  #15 0x000056286811eff1 in hmp_memory_dump (mon=0x56286a8c32d0, 
qdict=0x56286b15c400) at monitor/misc.c:785
  #16 0x00005628684740ee in handle_hmp_command (mon=0x56286a8c32d0, 
cmdline=0x56286a8caeb2 "0x40001010") at monitor/hmp.c:1082

>From the datasheet "Actel SmartFusion Microcontroller Subsystem
User's Guide" Rev.1, Table 13-3 "SPI Register Summary", this
register has a reset value of 0.

Check the FIFO is not empty before accessing it, else log an
error message.

Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Alistair Francis <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>


  Commit: a09ef5040477643a7026703199d8781fe048d3a8
      
https://github.com/qemu/qemu/commit/a09ef5040477643a7026703199d8781fe048d3a8
  Author: Philippe Mathieu-Daudé <address@hidden>
  Date:   2019-07-15 (Mon, 15 Jul 2019)

  Changed paths:
    M hw/display/xlnx_dp.c

  Log Message:
  -----------
  hw/display/xlnx_dp: Avoid crash when reading empty RX FIFO

In the previous commit we fixed a crash when the guest read a
register that pop from an empty FIFO.
By auditing the repository, we found another similar use with
an easy way to reproduce:

  $ qemu-system-aarch64 -M xlnx-zcu102 -monitor stdio -S
  QEMU 4.0.50 monitor - type 'help' for more information
  (qemu) xp/b 0xfd4a0134
  Aborted (core dumped)

  (gdb) bt
  #0  0x00007f6936dea57f in raise () at /lib64/libc.so.6
  #1  0x00007f6936dd4895 in abort () at /lib64/libc.so.6
  #2  0x0000561ad32975ec in xlnx_dp_aux_pop_rx_fifo (s=0x7f692babee70) at 
hw/display/xlnx_dp.c:431
  #3  0x0000561ad3297dc0 in xlnx_dp_read (opaque=0x7f692babee70, offset=77, 
size=4) at hw/display/xlnx_dp.c:667
  #4  0x0000561ad321b896 in memory_region_read_accessor (mr=0x7f692babf620, 
addr=308, value=0x7ffe05c1db88, size=4, shift=0, mask=4294967295, attrs=...) at 
memory.c:439
  #5  0x0000561ad321bd70 in access_with_adjusted_size (addr=308, 
value=0x7ffe05c1db88, size=1, access_size_min=4, access_size_max=4, 
access_fn=0x561ad321b858 <memory_region_read_accessor>, mr=0x7f692babf620, 
attrs=...) at memory.c:569
  #6  0x0000561ad321e9d5 in memory_region_dispatch_read1 (mr=0x7f692babf620, 
addr=308, pval=0x7ffe05c1db88, size=1, attrs=...) at memory.c:1420
  #7  0x0000561ad321ea9d in memory_region_dispatch_read (mr=0x7f692babf620, 
addr=308, pval=0x7ffe05c1db88, size=1, attrs=...) at memory.c:1447
  #8  0x0000561ad31bd742 in flatview_read_continue (fv=0x561ad69c04f0, 
addr=4249485620, attrs=..., buf=0x7ffe05c1dcf0 "\020\335\301\005\376\177", 
len=1, addr1=308, l=1, mr=0x7f692babf620) at exec.c:3385
  #9  0x0000561ad31bd895 in flatview_read (fv=0x561ad69c04f0, addr=4249485620, 
attrs=..., buf=0x7ffe05c1dcf0 "\020\335\301\005\376\177", len=1) at exec.c:3423
  #10 0x0000561ad31bd90b in address_space_read_full (as=0x561ad5bb3020, 
addr=4249485620, attrs=..., buf=0x7ffe05c1dcf0 "\020\335\301\005\376\177", 
len=1) at exec.c:3436
  #11 0x0000561ad33b1c42 in address_space_read (len=1, buf=0x7ffe05c1dcf0 
"\020\335\301\005\376\177", attrs=..., addr=4249485620, as=0x561ad5bb3020) at 
include/exec/memory.h:2131
  #12 0x0000561ad33b1c42 in memory_dump (mon=0x561ad59c4530, count=1, 
format=120, wsize=1, addr=4249485620, is_physical=1) at monitor/misc.c:723
  #13 0x0000561ad33b1fc1 in hmp_physical_memory_dump (mon=0x561ad59c4530, 
qdict=0x561ad6c6fd00) at monitor/misc.c:795
  #14 0x0000561ad37b4a9f in handle_hmp_command (mon=0x561ad59c4530, 
cmdline=0x561ad59d0f22 "/b 0x00000000fd4a0134") at monitor/hmp.c:1082

Fix by checking the FIFO is not empty before popping from it.

The datasheet is not clear about the reset value of this register,
we choose to return '0'.

Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Alistair Francis <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 80734cbdcab6ddb8d45a75910e8f7e3841daca2c
      
https://github.com/qemu/qemu/commit/80734cbdcab6ddb8d45a75910e8f7e3841daca2c
  Author: David Engraf <address@hidden>
  Date:   2019-07-15 (Mon, 15 Jul 2019)

  Changed paths:
    M hw/arm/virt.c

  Log Message:
  -----------
  hw/arm/virt: Fix non-secure flash mode

Using the whole 128 MiB flash in non-secure mode is not working because
virt_flash_fdt() expects the same address for secure_sysmem and sysmem.
This is not correctly handled by caller because it forwards NULL for
secure_sysmem in non-secure flash mode.

Fixed by using sysmem when secure_sysmem is NULL.

Signed-off-by: David Engraf <address@hidden>
Message-id: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 032cfe6a79c842a47cb8cc911c9961eb7ca51a98
      
https://github.com/qemu/qemu/commit/032cfe6a79c842a47cb8cc911c9961eb7ca51a98
  Author: Peter Maydell <address@hidden>
  Date:   2019-07-15 (Mon, 15 Jul 2019)

  Changed paths:
    M hw/core/machine.c
    M hw/timer/pl031.c
    M include/hw/timer/pl031.h

  Log Message:
  -----------
  pl031: Correctly migrate state when using -rtc clock=host

The PL031 RTC tracks the difference between the guest RTC
and the host RTC using a tick_offset field. For migration,
however, we currently always migrate the offset between
the guest and the vm_clock, even if the RTC clock is not
the same as the vm_clock; this was an attempt to retain
migration backwards compatibility.

Unfortunately this results in the RTC behaving oddly across
a VM state save and restore -- since the VM clock stands still
across save-then-restore, regardless of how much real world
time has elapsed, the guest RTC ends up out of sync with the
host RTC in the restored VM.

Fix this by migrating the raw tick_offset. To retain migration
compatibility as far as possible, we have a new property
migrate-tick-offset; by default this is 'true' and we will
migrate the true tick offset in a new subsection; if the
incoming data has no subsection we fall back to the old
vm_clock-based offset information, so old->new migration
compatibility is preserved. For complete new->old migration
compatibility, the property is set to 'false' for 4.0 and
earlier machine types (this will only affect 'virt-4.0'
and below, as none of the other pl031-using machines are
versioned).

Reported-by: Russell King <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Dr. David Alan Gilbert <address@hidden>
Message-id: address@hidden


  Commit: cb7cef8b32033f6284a47d797edd5c19c5491698
      
https://github.com/qemu/qemu/commit/cb7cef8b32033f6284a47d797edd5c19c5491698
  Author: Peter Maydell <address@hidden>
  Date:   2019-07-15 (Mon, 15 Jul 2019)

  Changed paths:
    M target/arm/cpu.c

  Log Message:
  -----------
  target/arm: Set VFP-related MVFR0 fields for arm926 and arm1026

The ARMv5 architecture didn't specify detailed per-feature ID
registers. Now that we're using the MVFR0 register fields to
gate the existence of VFP instructions, we need to set up
the correct values in the cpu->isar structure so that we still
provide an FPU to the guest.

This fixes a regression in the arm926 and arm1026 CPUs, which
are the only ones that both have VFP and are ARMv5 or earlier.
This regression was introduced by the VFP refactoring, and more
specifically by commits 1120827fa182f0e76 and 266bd25c485597c,
which accidentally disabled VFP short-vector support and
double-precision support on these CPUs.

Fixes: 1120827fa182f0e
Fixes: 266bd25c485597c
Fixes: https://bugs.launchpad.net/qemu/+bug/1836192
Reported-by: Christophe Lyon <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Reviewed-by: Alex Bennée <address@hidden>
Tested-by: Christophe Lyon <address@hidden>
Message-id: address@hidden


  Commit: 51c9122e92b776a3f16af0b9282f1dc5012e2a19
      
https://github.com/qemu/qemu/commit/51c9122e92b776a3f16af0b9282f1dc5012e2a19
  Author: Peter Maydell <address@hidden>
  Date:   2019-07-15 (Mon, 15 Jul 2019)

  Changed paths:
    M target/arm/m_helper.c

  Log Message:
  -----------
  target/arm: NS BusFault on vector table fetch escalates to NS HardFault

In the M-profile architecture, when we do a vector table fetch and it
fails, we need to report a HardFault.  Whether this is a Secure HF or
a NonSecure HF depends on several things.  If AIRCR.BFHFNMINS is 0
then HF is always Secure, because there is no NonSecure HardFault.
Otherwise, the answer depends on whether the 'underlying exception'
(MemManage, BusFault, SecureFault) targets Secure or NonSecure.  (In
the pseudocode, this is handled in the Vector() function: the final
exc.isSecure is calculated by looking at the exc.isSecure from the
exception returned from the memory access, not the isSecure input
argument.)

We weren't doing this correctly, because we were looking at
the target security domain of the exception we were trying to
load the vector table entry for. This produces errors of two kinds:
 * a load from the NS vector table which hits the "NS access
   to S memory" SecureFault should end up as a Secure HardFault,
   but we were raising an NS HardFault
 * a load from the S vector table which causes a BusFault
   should raise an NS HardFault if BFHFNMINS == 1 (because
   in that case all BusFaults are NonSecure), but we were raising
   a Secure HardFault

Correct the logic.

We also fix a comment error where we claimed that we might
be escalating MemManage to HardFault, and forgot about SecureFault.
(Vector loads can never hit MPU access faults, because they're
always aligned and always use the default address map.)

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


  Commit: 0dc6284710afa2342fbe3932f4a73c41204da8e9
      
https://github.com/qemu/qemu/commit/0dc6284710afa2342fbe3932f4a73c41204da8e9
  Author: Peter Maydell <address@hidden>
  Date:   2019-07-15 (Mon, 15 Jul 2019)

  Changed paths:
    M hw/arm/virt.c
    M hw/core/machine.c
    M hw/display/xlnx_dp.c
    M hw/ssi/mss-spi.c
    M hw/ssi/xilinx_spips.c
    M hw/timer/pl031.c
    M include/hw/timer/pl031.h
    M target/arm/cpu.c
    M target/arm/m_helper.c

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

target-arm queue:
 * report ARMv8-A FP support for AArch32 -cpu max
 * hw/ssi/xilinx_spips: Avoid AXI writes to the LQSPI linear memory
 * hw/ssi/xilinx_spips: Avoid out-of-bound access to lqspi_buf[]
 * hw/ssi/mss-spi: Avoid crash when reading empty RX FIFO
 * hw/display/xlnx_dp: Avoid crash when reading empty RX FIFO
 * hw/arm/virt: Fix non-secure flash mode
 * pl031: Correctly migrate state when using -rtc clock=host
 * fix regression that meant arm926 and arm1026 lost VFP
   double-precision support
 * v8M: NS BusFault on vector table fetch escalates to NS HardFault

# gpg: Signature made Mon 15 Jul 2019 14:41:25 BST
# 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-20190715:
  target/arm: NS BusFault on vector table fetch escalates to NS HardFault
  target/arm: Set VFP-related MVFR0 fields for arm926 and arm1026
  pl031: Correctly migrate state when using -rtc clock=host
  hw/arm/virt: Fix non-secure flash mode
  hw/display/xlnx_dp: Avoid crash when reading empty RX FIFO
  hw/ssi/mss-spi: Avoid crash when reading empty RX FIFO
  hw/ssi/xilinx_spips: Avoid out-of-bound access to lqspi_buf[]
  hw/ssi/xilinx_spips: Avoid AXI writes to the LQSPI linear memory
  hw/ssi/xilinx_spips: Convert lqspi_read() to read_with_attrs
  target/arm: report ARMv8-A FP support for AArch32 -cpu max

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


Compare: https://github.com/qemu/qemu/compare/b9404bf592e7...0dc6284710af