[Qemu-commits] [qemu/qemu] c6e984: loongarch: Change the UEFI loading mode to loongarch

[Peter Maydell]

  Branch: refs/heads/staging
  Home:   https://github.com/qemu/qemu
  Commit: c6e9847fc4becba561c631c4505e3b05d4926184
      
https://github.com/qemu/qemu/commit/c6e9847fc4becba561c631c4505e3b05d4926184
  Author: Xianglai Li <lixianglai@loongson.cn>
  Date:   2024-02-29 (Thu, 29 Feb 2024)

  Changed paths:
    M hw/loongarch/acpi-build.c
    M hw/loongarch/virt.c
    M include/hw/loongarch/virt.h

  Log Message:
  -----------
  loongarch: Change the UEFI loading mode to loongarch

The UEFI loading mode in loongarch is very different
from that in other architectures:loongarch's UEFI code
is in rom, while other architectures' UEFI code is in flash.

loongarch UEFI can be loaded as follows:
-machine virt,pflash=pflash0-format
-bios ./QEMU_EFI.fd

Other architectures load UEFI using the following methods:
-machine virt,pflash0=pflash0-format,pflash1=pflash1-format

loongarch's UEFI loading method makes qemu and libvirt incompatible
when using NVRAM, and the cost of loongarch's current loading method
far outweighs the benefits, so we decided to use the same UEFI loading
scheme as other architectures.

Cc: Andrea Bolognani <abologna@redhat.com>
Cc: maobibo@loongson.cn
Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
Cc: Song Gao <gaosong@loongson.cn>
Cc: zhaotianrui@loongson.cn
Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
Tested-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-Id: 
<0bd892aa9b88e0f4cc904cb70efd0251fc1cde29.1708336919.git.lixianglai@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>


  Commit: 2791490de1c6dabba7fe1a6ab3149384e444f412
      
https://github.com/qemu/qemu/commit/2791490de1c6dabba7fe1a6ab3149384e444f412
  Author: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
  Date:   2024-03-01 (Fri, 01 Mar 2024)

  Changed paths:
    M tests/qtest/libqos/virtio.c

  Log Message:
  -----------
  libqos/virtio.c: init all elems in qvring_indirect_desc_setup()

The loop isn't setting the values for the last element. Every other
element is being initialized with addr = 0, flags = VRING_DESC_F_NEXT
and next = i + 1. The last elem is never touched.

This became a problem when enabling a RISC-V 'virt' libqos machine in
the 'indirect' test of virti-blk-test.c. The 'flags' for the last
element will end up being an odd number (since we didn't touch it).
Being an odd number it will be mistaken by VRING_DESC_F_NEXT, which
happens to be 1.

Deep into hw/virt/virtio.c, in virtqueue_split_pop(), into
virtqueue_split_read_next_desc(), a check for VRING_DESC_F_NEXT will be
made to see if we're supposed to chain. The code will keep up chaining
in the last element because the uninitialized value happens to be odd.
We'll error out right after that because desc->next (which is also
uninitialized) will be >= max. A VIRTQUEUE_READ_DESC_ERROR will be
returned, with an error message like this in the stderr:

qemu-system-riscv64: Desc next is 49391

Since we never returned, we'll end up timing out at qvirtio_wait_used_elem():

ERROR:../tests/qtest/libqos/virtio.c:236:qvirtio_wait_used_elem:
    assertion failed: (g_get_monotonic_time() - start_time <= timeout_us)

The root cause is using uninitialized values from guest_alloc() in
qvring_indirect_desc_setup(). There's no guarantee that the memory pages
retrieved will be zeroed, so we can't make assumptions. In fact, commit
5b4f72f5e8 ("tests/qtest: properly initialise the vring used idx") fixed a
similar problem stating "It is probably not wise to assume guest memory
is zeroed anyway". I concur.

Initialize all elems in qvring_indirect_desc_setup().

Fixes: f294b029aa ("libqos: Added indirect descriptor support to virtio 
implementation")
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20240217192607.32565-2-dbarboza@ventanamicro.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>


  Commit: 3283843a8ed3271cd9cef6e30232dfad8a2fb407
      
https://github.com/qemu/qemu/commit/3283843a8ed3271cd9cef6e30232dfad8a2fb407
  Author: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
  Date:   2024-03-01 (Fri, 01 Mar 2024)

  Changed paths:
    M tests/qtest/libqos/virtio.c

  Log Message:
  -----------
  libqos/virtio.c: fix 'avail_event' offset in qvring_init()

In qvring_init() we're writing vq->used->avail_event at "vq->used + 2 +
array_size".  The struct pointed by vq->used is, from virtio_ring.h
Linux header):

 *      // A ring of used descriptor heads with free-running index.
 *      __virtio16 used_flags;
 *      __virtio16 used_idx;
 *      struct vring_used_elem used[num];
 *      __virtio16 avail_event_idx;

So 'flags' is the word right at vq->used. 'idx' is vq->used + 2. We need
to skip 'used_idx' by adding + 2 bytes, and then sum the vector size, to
reach avail_event_idx. An example on how to properly access this field
can be found in qvirtqueue_kick():

avail_event = qvirtio_readw(d, qts, vq->used + 4 +
                            sizeof(struct vring_used_elem) * vq->size);

This error was detected when enabling the RISC-V 'virt' libqos machine.
The 'idx' test from vhost-user-blk-test.c errors out with a timeout in
qvirtio_wait_used_elem(). The timeout happens because when processing
the first element, 'avail_event' is read in qvirtqueue_kick() as non-zero
because we didn't initialize it properly (and the memory at that point
happened to be non-zero). 'idx' is 0.

All of this makes this condition fail because "idx - avail_event" will
overflow and be non-zero:

/* < 1 because we add elements to avail queue one by one */
if ((flags & VRING_USED_F_NO_NOTIFY) == 0 &&
                        (!vq->event || (uint16_t)(idx-avail_event) < 1)) {
    d->bus->virtqueue_kick(d, vq);
}

As a result the virtqueue is never kicked and we'll timeout waiting for it.

Fixes: 1053587c3f ("libqos: Added EVENT_IDX support")
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20240217192607.32565-3-dbarboza@ventanamicro.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>


  Commit: 8bd3f84d1f6fba0edebc450be6fa2c7630584df9
      
https://github.com/qemu/qemu/commit/8bd3f84d1f6fba0edebc450be6fa2c7630584df9
  Author: Thomas Huth <thuth@redhat.com>
  Date:   2024-03-01 (Fri, 01 Mar 2024)

  Changed paths:
    M hw/intc/Kconfig

  Log Message:
  -----------
  hw/intc/Kconfig: Fix GIC settings when using "--without-default-devices"

When using "--without-default-devices", the ARM_GICV3_TCG and ARM_GIC_KVM
settings currently get disabled, though the arm virt machine is only of
very limited use in that case. This also causes the migration-test to
fail in such builds. Let's make sure that we always keep the GIC switches
enabled in the --without-default-devices builds, too.

Message-ID: <20240221110059.152665-1-thuth@redhat.com>
Tested-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Thomas Huth <thuth@redhat.com>


  Commit: 5e02a4fdebc442e34c5bb05e4540f85cc6e802f0
      
https://github.com/qemu/qemu/commit/5e02a4fdebc442e34c5bb05e4540f85cc6e802f0
  Author: Benjamin David Lunt <benlunt@fysnet.net>
  Date:   2024-03-01 (Fri, 01 Mar 2024)

  Changed paths:
    M hw/usb/bus.c

  Log Message:
  -----------
  hw/usb/bus.c: PCAP adding 0xA in Windows version

Since Windows text files use CRLFs for all \n, the Windows version of QEMU
inserts a CR in the PCAP stream when a LF is encountered when using USB PCAP
files. This is due to the fact that the PCAP file is opened as TEXT instead
of BINARY.

To show an example, when using a very common protocol to USB disks, the BBB
protocol uses a 10-byte command packet. For example, the READ_CAPACITY(10)
command will have a command block length of 10 (0xA). When this 10-byte
command (part of the 31-byte CBW) is placed into the PCAP file, the Windows
file manager inserts a 0xD before the 0xA, turning the 31-byte CBW into a
32-byte CBW.

Actual CBW:
  0040 55 53 42 43 01 00 00 00 08 00 00 00 80 00 0a 25 USBC...........%
  0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00       ...............

PCAP CBW
  0040 55 53 42 43 01 00 00 00 08 00 00 00 80 00 0d 0a USBC............
  0050 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 %..............

I believe simply opening the PCAP file as BINARY instead of TEXT will fix
this issue.

Resolves: https://bugs.launchpad.net/qemu/+bug/2054889
Signed-off-by: Benjamin David Lunt <benlunt@fysnet.net>
Message-ID: <000101da6823$ce1bbf80$6a533e80$@fysnet.net>
[thuth: Break long line to avoid checkpatch.pl error]
Signed-off-by: Thomas Huth <thuth@redhat.com>


  Commit: f0cb6828ae34fb56fbb869bb3147a636d1c984ce
      
https://github.com/qemu/qemu/commit/f0cb6828ae34fb56fbb869bb3147a636d1c984ce
  Author: Thomas Huth <thuth@redhat.com>
  Date:   2024-03-01 (Fri, 01 Mar 2024)

  Changed paths:
    M tests/unit/test-util-sockets.c

  Log Message:
  -----------
  tests/unit/test-util-sockets: Remove temporary file after test

test-util-sockets leaves the temporary socket files around in the
temporary files folder. Let's better remove them at the end of the
testing.

Fixes: 4d3a329af5 ("tests/util-sockets: add abstract unix socket cases")
Message-ID: <20240226082728.249753-1-thuth@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>


  Commit: 462945cd22d2bcd233401ed3aa167d83a8e35b05
      
https://github.com/qemu/qemu/commit/462945cd22d2bcd233401ed3aa167d83a8e35b05
  Author: Thomas Huth <thuth@redhat.com>
  Date:   2024-03-01 (Fri, 01 Mar 2024)

  Changed paths:
    M chardev/char-socket.c

  Log Message:
  -----------
  chardev/char-socket: Fix TLS io channels sending too much data to the backend

Commit ffda5db65a ("io/channel-tls: fix handling of bigger read buffers")
changed the behavior of the TLS io channels to schedule a second reading
attempt if there is still incoming data pending. This caused a regression
with backends like the sclpconsole that check in their read function that
the sender does not try to write more bytes to it than the device can
currently handle.

The problem can be reproduced like this:

 1) In one terminal, do this:

  mkdir qemu-pki
  cd qemu-pki
  openssl genrsa 2048 > ca-key.pem
  openssl req -new -x509 -nodes -days 365000 -key ca-key.pem -out ca-cert.pem
  # enter some dummy value for the cert
  openssl genrsa 2048 > server-key.pem
  openssl req -new -x509 -nodes -days 365000 -key server-key.pem \
    -out server-cert.pem
  # enter some other dummy values for the cert

  gnutls-serv --echo --x509cafile ca-cert.pem --x509keyfile server-key.pem \
              --x509certfile server-cert.pem -p 8338

 2) In another terminal, do this:

  wget 
https://download.fedoraproject.org/pub/fedora-secondary/releases/39/Cloud/s390x/images/Fedora-Cloud-Base-39-1.5.s390x.qcow2

  qemu-system-s390x -nographic -nodefaults \
    -hda Fedora-Cloud-Base-39-1.5.s390x.qcow2 \
    -object 
tls-creds-x509,id=tls0,endpoint=client,verify-peer=false,dir=$PWD/qemu-pki \
    -chardev socket,id=tls_chardev,host=localhost,port=8338,tls-creds=tls0 \
    -device sclpconsole,chardev=tls_chardev,id=tls_serial

QEMU then aborts after a second or two with:

  qemu-system-s390x: ../hw/char/sclpconsole.c:73: chr_read: Assertion
   `size <= SIZE_BUFFER_VT220 - scon->iov_data_len' failed.
 Aborted (core dumped)

It looks like the second read does not trigger the chr_can_read() function
to be called before the second read, which should normally always be done
before sending bytes to a character device to see how much it can handle,
so the s->max_size in tcp_chr_read() still contains the old value from the
previous read. Let's make sure that we use the up-to-date value by calling
tcp_chr_read_poll() again here.

Fixes: ffda5db65a ("io/channel-tls: fix handling of bigger read buffers")
Buglink: https://issues.redhat.com/browse/RHEL-24614
Reviewed-by: "Daniel P. Berrangé" <berrange@redhat.com>
Message-ID: <20240229104339.42574-1-thuth@redhat.com>
Reviewed-by: Antoine Damhet <antoine.damhet@blade-group.com>
Tested-by: Antoine Damhet <antoine.damhet@blade-group.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>


  Commit: b21d5fd180c202bea162b5ed8b862be2302a2cda
      
https://github.com/qemu/qemu/commit/b21d5fd180c202bea162b5ed8b862be2302a2cda
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2024-03-01 (Fri, 01 Mar 2024)

  Changed paths:
    M hw/loongarch/acpi-build.c
    M hw/loongarch/virt.c
    M include/hw/loongarch/virt.h

  Log Message:
  -----------
  Merge tag 'pull-loongarch-20240229' of https://gitlab.com/gaosong/qemu into 
staging

pull-loongarch-20240229

V2: fix build error on mipsel

# -----BEGIN PGP SIGNATURE-----
#
# iLMEAAEKAB0WIQS4/x2g0v3LLaCcbCxAov/yOSY+3wUCZeBrwAAKCRBAov/yOSY+
# 33YXA/4+A5Bpe/3+mSAWZSUlluGTqUi0ILBYRMyX1RXovMx4uCRGr7PXzAf03yKS
# MZzlVzTuOK69WmTm/iTdYWOxkXisC3gzxL/wm8hP4lzh4c0dHrHRsKHqq6gR3+t2
# ojdZn7TefeflnNqIhxXxgxb1OETofhBNnBJ74pvqxO7XV5SWnA==
# =J2Kb
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 29 Feb 2024 11:34:24 GMT
# gpg:                using RSA key B8FF1DA0D2FDCB2DA09C6C2C40A2FFF239263EDF
# gpg: Good signature from "Song Gao <m17746591750@163.com>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: B8FF 1DA0 D2FD CB2D A09C  6C2C 40A2 FFF2 3926 3EDF

* tag 'pull-loongarch-20240229' of https://gitlab.com/gaosong/qemu:
  loongarch: Change the UEFI loading mode to loongarch

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


  Commit: e1007b6bab5cf97705bf4f2aaec1f607787355b8
      
https://github.com/qemu/qemu/commit/e1007b6bab5cf97705bf4f2aaec1f607787355b8
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2024-03-01 (Fri, 01 Mar 2024)

  Changed paths:
    M chardev/char-socket.c
    M hw/intc/Kconfig
    M hw/usb/bus.c
    M tests/qtest/libqos/virtio.c
    M tests/unit/test-util-sockets.c

  Log Message:
  -----------
  Merge tag 'pull-request-2024-03-01' of https://gitlab.com/thuth/qemu into 
staging

* Fix some bugs in the vring setup of libqos
* Fix GIC settings when using --without-default-devices
* Fix USB PCAP streams on Windows
* Remove temporary files from test-util-sockets
* Fix TLS io channels sending too much data to the backend

# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmXhjBcRHHRodXRoQHJl
# ZGhhdC5jb20ACgkQLtnXdP5wLbWzZw/+OTSsKg6JTX0z3fjL6If+Ns/EnFiniHHI
# y1jR7fPub3ybFokgHIWrRVG+9ol+1tJuPlO5Bsx1SKFzNC8++l1iyK7E25xnmp2P
# Ry/Z0ZSWp3JWCtLm6km5pKl3wWI9p0XwfUOJbCWYM5dOsd2a4C4DSvjcwNXR7pTB
# 4AxXFj5G5UwXuffgPnBzeerm5baNweSqa/uczUY6Od+iJwmHpaSk0SJ4NIlIYvnS
# z3BH81trQAoKYZyywp0aF+jH9w3YNwD1XDp2Bcf3qSWDdokN55V13yyiSllTfUwX
# Lq3fotoLqFJL0A4m8a3TdCKMP8ReoJATSriPHJmGMgqWGTnvtRBIsx1pmMpYRB6U
# EltaKW0WXeQAad0ZYGl4odx7kQUQjdc8HTQRTevQD9g3XpZZN0o9MfTPdM2eR5h6
# xaS8UEc61YJAcmD27Ir92JGGGMLBTYz4OGLx3Rj7l7S759GQ67qih9TGcE9nqSj+
# +wAHfiOjUZnSWnp7Hq4M/TIjNh0BuyBW4oRBASaikjjQ82Hih5bPTdRu1J8lYuXC
# PhN8dLwdk0NMrnnHuFDKq/sXjDeXF3Hg0AmtVvOGiB2z2OeVSPtMxl/YgniGVTbj
# CHXDqDrBAa7i6WxAo+TtUgE20iVz5uYzGqHmxTNpq6FzIRb1uvHksbjFlin79Pkw
# eF0Dj80zxAY=
# =9JAI
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 01 Mar 2024 08:04:39 GMT
# gpg:                using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5
# gpg:                issuer "thuth@redhat.com"
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full]
# gpg:                 aka "Thomas Huth <thuth@redhat.com>" [full]
# gpg:                 aka "Thomas Huth <huth@tuxfamily.org>" [full]
# gpg:                 aka "Thomas Huth <th.huth@posteo.de>" [unknown]
# Primary key fingerprint: 27B8 8847 EEE0 2501 18F3  EAB9 2ED9 D774 FE70 2DB5

* tag 'pull-request-2024-03-01' of https://gitlab.com/thuth/qemu:
  chardev/char-socket: Fix TLS io channels sending too much data to the backend
  tests/unit/test-util-sockets: Remove temporary file after test
  hw/usb/bus.c: PCAP adding 0xA in Windows version
  hw/intc/Kconfig: Fix GIC settings when using "--without-default-devices"
  libqos/virtio.c: fix 'avail_event' offset in qvring_init()
  libqos/virtio.c: init all elems in qvring_indirect_desc_setup()

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


Compare: https://github.com/qemu/qemu/compare/c0c6a0e3528b...e1007b6bab5c

To unsubscribe from these emails, change your notification settings at 
https://github.com/qemu/qemu/settings/notifications