Skip to content
GitLab
Select Git revision
  1. 10 Aug, 2021 1 commit
  3. 06 Aug, 2021 1 commit
  5. 20 Jul, 2021 2 commits
  7. 12 Jul, 2021 1 commit
  9. 28 May, 2021 1 commit
  11. 22 May, 2021 2 commits
  13. 10 May, 2021 1 commit
  15. 29 Apr, 2021 2 commits
  17. 15 Sep, 2020 2 commits
    • Michael Roth's avatar
      Update version for 5.0.1 release · 386b2a57
      Michael Roth authored 
      
Signed-off-by: default avatarMichael Roth <mdroth@linux.vnet.ibm.com>
      v5.0.1
      386b2a57
    • Nathan Chancellor's avatar
      riscv: sifive_test: Allow 16-bit writes to memory region · 5c49f7ee
      Nathan Chancellor authored 
      When shutting down the machine running a mainline Linux kernel, the
following error happens:

$ build/riscv64-softmmu/qemu-system-riscv64 -bios default -M virt \
    -display none -initrd rootfs.cpio -kernel Image -m 512m \
    -nodefaults -serial mon:stdio
...
Requesting system poweroff
[    4.999630] reboot: Power down
sbi_trap_error: hart0: trap handler failed (error -2)
sbi_trap_error: hart0: mcause=0x0000000000000007 mtval=0x0000000000100000
sbi_trap_error: hart0: mepc=0x000000008000d4cc mstatus=0x0000000000001822
sbi_trap_error: hart0: ra=0x000000008000999e sp=0x0000000080015c78
sbi_trap_error: hart0: gp=0xffffffe000e76610 tp=0xffffffe0081b89c0
sbi_trap_error: hart0: s0=0x0000000080015c88 s1=0x0000000000000040
sbi_trap_error: hart0: a0=0x0000000000000000 a1=0x0000000080004024
sbi_trap_error: hart0: a2=0x0000000080004024 a3=0x0000000080004024
sbi_trap_error: hart0: a4=0x0000000000100000 a5=0x0000000000005555
sbi_trap_error: hart0: a6=0x0000000000004024 a7=0x0000000080011158
sbi_trap_error: hart0: s2=0x0000000000000000 s3=0x0000000080016000
sbi_trap_error: hart0: s4=0x0000000000000000 s5=0x0000000000000000
sbi_trap_error: hart0: s6=0x0000000000000001 s7=0x0000000000000000
sbi_trap_error: hart0: s8=0x0000000000000000 s9=0x0000000000000000
sbi_trap_error: hart0: s10=0x0000000000000000 s11=0x0000000000000008
sbi_trap_error: hart0: t0=0x0000000000000000 t1=0x0000000000000000
sbi_trap_error: hart0: t2=0x0000000000000000 t3=0x0000000000000000
sbi_trap_error: hart0: t4=0x0000000000000000 t5=0x0000000000000000
sbi_trap_error: hart0: t6=0x0000000000000000

The kernel does a 16-bit write when powering off the machine, which
was allowed before commit 5d971f9e ("memory: Revert "memory: accept
mismatching sizes in memory_region_access_valid""). Make min_access_size
match reality so that the machine can shut down properly now.

Cc: qemu-stable@nongnu.org
Fixes: 88a07990 ("SiFive RISC-V Test Finisher")
Fixes: 5d971f9e

 ("memory: Revert "memory: accept mismatching sizes in memory_region_access_valid"")
Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: default avatarAlistair Francis <alistair.francis@wdc.com>
Message-Id: <20200901055822.2721209-1-natechancellor@gmail.com>
Signed-off-by: default avatarAlistair Francis <alistair.francis@wdc.com>
(cherry picked from commit ab3d207f

)
Signed-off-by: default avatarMichael Roth <mdroth@linux.vnet.ibm.com>
      5c49f7ee
  19. 10 Sep, 2020 2 commits
    • Halil Pasic's avatar
      virtio-ccw: fix virtio_set_ind_atomic · b8fdfa9d
      Halil Pasic authored 
      The atomic_cmpxchg() loop is broken because we occasionally end up with
old and _old having different values (a legit compiler can generate code
that accessed *ind_addr again to pick up a value for _old instead of
using the value of old that was already fetched according to the
rules of the abstract machine). This means the underlying CS instruction
may use a different old (_old) than the one we intended to use if
atomic_cmpxchg() performed the xchg part.

Let us use volatile to force the rules of the abstract machine for
accesses to *ind_addr. Let us also rewrite the loop so, we that the
new old is used to compute the new desired value if the xchg part
is not performed.

Fixes: 7e749462

 ("s390x/virtio-ccw: Adapter interrupt support.")
Reported-by: default avatarAndre Wild <Andre.Wild1@ibm.com>
Signed-off-by: default avatarHalil Pasic <pasic@linux.ibm.com>
Reviewed-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20200616045035.51641-2-pasic@linux.ibm.com>
Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
(cherry picked from commit 1a8242f7

)
Signed-off-by: default avatarMichael Roth <mdroth@linux.vnet.ibm.com>
      b8fdfa9d
    • Greg Kurz's avatar
      nvram: Exit QEMU if NVRAM cannot contain all -prom-env data · ebf5b394
      Greg Kurz authored 
      Since commit 61f20b9d ("spapr_nvram: Pre-initialize the NVRAM to
support the -prom-env parameter"), pseries machines can pre-initialize
the "system" partition in the NVRAM with the data passed to all -prom-env
parameters on the QEMU command line.

In this case it is assumed that all the data fits in 64 KiB, but the user
can easily pass more and crash QEMU:

$ qemu-system-ppc64 -M pseries $(for ((x=0;x<128;x++)); do \
  echo -n " -prom-env " ; printf "%0.sx" {1..1024}; \
  done) # this requires ~128 Kib
malloc(): corrupted top size
Aborted (core dumped)

This happens because we don't check if all the prom-env data fits in
the NVRAM and chrp_nvram_set_var() happily memcpy() it passed the
buffer.

This crash affects basically all ppc/ppc64 machine types that use -prom-env:
- pseries (all versions)
- g3beige
- mac99

and also sparc/sparc64 machine types:
- LX
- SPARCClassic
- SPARCbook
- SS-10
- SS-20
- SS-4
- SS-5
- SS-600MP
- Voyager
- sun4u
- sun4v

Add a max_len argument to chrp_nvram_create_system_partition() so that
it can check the available size before writing to memory.

Since NVRAM is populated at machine init, it seems reasonable to consider
this error as fatal. So, instead of reporting an error when we detect that
the NVRAM is too small and adapt all machine types to handle it, we simply
exit QEMU in all cases. This is still better than crashing. If someone
wants another behavior, I guess this can be reworked later.

Tested with:

$ yes q | \
  (for arch in ppc ppc64 sparc sparc64; do \
       echo == $arch ==; \
       qemu=${arch}-softmmu/qemu-system-$arch; \
       for mach in $($qemu -M help | awk '! /^Supported/ { print $1 }'); do \
           echo $mach; \
           $qemu -M $mach -monitor stdio -nodefaults -nographic \
           $(for ((x=0;x<128;x++)); do \
                 echo -n " -prom-env " ; printf "%0.sx" {1..1024}; \
             done) >/dev/null; \
        done; echo; \
   done)

Without the patch, affected machine types cause QEMU to report some
memory corruption and crash:

malloc(): corrupted top size

free(): invalid size

*** stack smashing detected ***: terminated

With the patch, QEMU prints the following message and exits:

NVRAM is too small. Try to pass less data to -prom-env

It seems that the conditions for the crash have always existed, but it
affects pseries, the machine type I care for, since commit 61f20b9d
only.

Fixes: 61f20b9d ("spapr_nvram: Pre-initialize the NVRAM to support the -prom-env parameter")
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1867739


Reported-by: default avatarJohn Snow <jsnow@redhat.com>
Reviewed-by: default avatarLaurent Vivier <laurent@vivier.eu>
Signed-off-by: default avatarGreg Kurz <groug@kaod.org>
Message-Id: <159736033937.350502.12402444542194031035.stgit@bahia.lan>
Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit 37035df5

)
Signed-off-by: default avatarMichael Roth <mdroth@linux.vnet.ibm.com>
      ebf5b394
  21. 09 Sep, 2020 12 commits
  23. 03 Sep, 2020 13 commits