From 2791490de1c6dabba7fe1a6ab3149384e444f412 Mon Sep 17 00:00:00 2001 From: Daniel Henrique Barboza Date: Sat, 17 Feb 2024 16:26:02 -0300 Subject: [PATCH 1/6] 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 Reviewed-by: Alistair Francis Reviewed-by: Thomas Huth Message-ID: <20240217192607.32565-2-dbarboza@ventanamicro.com> Signed-off-by: Thomas Huth --- tests/qtest/libqos/virtio.c | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/tests/qtest/libqos/virtio.c b/tests/qtest/libqos/virtio.c index 410513225f..4f39124eba 100644 --- a/tests/qtest/libqos/virtio.c +++ b/tests/qtest/libqos/virtio.c @@ -280,14 +280,27 @@ QVRingIndirectDesc *qvring_indirect_desc_setup(QTestState *qs, QVirtioDevice *d, indirect->elem = elem; indirect->desc = guest_alloc(alloc, sizeof(struct vring_desc) * elem); - for (i = 0; i < elem - 1; ++i) { + for (i = 0; i < elem; ++i) { /* indirect->desc[i].addr */ qvirtio_writeq(d, qs, indirect->desc + (16 * i), 0); - /* indirect->desc[i].flags */ - qvirtio_writew(d, qs, indirect->desc + (16 * i) + 12, - VRING_DESC_F_NEXT); - /* indirect->desc[i].next */ - qvirtio_writew(d, qs, indirect->desc + (16 * i) + 14, i + 1); + + /* + * If it's not the last element of the ring, set + * the chain (VRING_DESC_F_NEXT) flag and + * desc->next. Clear the last element - there's + * no guarantee that guest_alloc() will do it. + */ + if (i != elem - 1) { + /* indirect->desc[i].flags */ + qvirtio_writew(d, qs, indirect->desc + (16 * i) + 12, + VRING_DESC_F_NEXT); + + /* indirect->desc[i].next */ + qvirtio_writew(d, qs, indirect->desc + (16 * i) + 14, i + 1); + } else { + qvirtio_writew(d, qs, indirect->desc + (16 * i) + 12, 0); + qvirtio_writew(d, qs, indirect->desc + (16 * i) + 14, 0); + } } return indirect; From 3283843a8ed3271cd9cef6e30232dfad8a2fb407 Mon Sep 17 00:00:00 2001 From: Daniel Henrique Barboza Date: Sat, 17 Feb 2024 16:26:03 -0300 Subject: [PATCH 2/6] 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 Reviewed-by: Alistair Francis Reviewed-by: Thomas Huth Message-ID: <20240217192607.32565-3-dbarboza@ventanamicro.com> Signed-off-by: Thomas Huth --- tests/qtest/libqos/virtio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/qtest/libqos/virtio.c b/tests/qtest/libqos/virtio.c index 4f39124eba..82a6e122bf 100644 --- a/tests/qtest/libqos/virtio.c +++ b/tests/qtest/libqos/virtio.c @@ -265,7 +265,7 @@ void qvring_init(QTestState *qts, const QGuestAllocator *alloc, QVirtQueue *vq, /* vq->used->idx */ qvirtio_writew(vq->vdev, qts, vq->used + 2, 0); /* vq->used->avail_event */ - qvirtio_writew(vq->vdev, qts, vq->used + 2 + + qvirtio_writew(vq->vdev, qts, vq->used + 4 + sizeof(struct vring_used_elem) * vq->size, 0); } From 8bd3f84d1f6fba0edebc450be6fa2c7630584df9 Mon Sep 17 00:00:00 2001 From: Thomas Huth Date: Wed, 21 Feb 2024 12:00:59 +0100 Subject: [PATCH 3/6] 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 Signed-off-by: Thomas Huth --- hw/intc/Kconfig | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/hw/intc/Kconfig b/hw/intc/Kconfig index 97d550b06b..2b5b2d2301 100644 --- a/hw/intc/Kconfig +++ b/hw/intc/Kconfig @@ -12,10 +12,6 @@ config IOAPIC bool select I8259 -config ARM_GIC - bool - select MSI_NONBROKEN - config OPENPIC bool select MSI_NONBROKEN @@ -25,14 +21,18 @@ config APIC select MSI_NONBROKEN select I8259 +config ARM_GIC + bool + select ARM_GICV3_TCG if TCG + select ARM_GIC_KVM if KVM + select MSI_NONBROKEN + config ARM_GICV3_TCG bool - default y depends on ARM_GIC && TCG config ARM_GIC_KVM bool - default y depends on ARM_GIC && KVM config XICS From 5e02a4fdebc442e34c5bb05e4540f85cc6e802f0 Mon Sep 17 00:00:00 2001 From: Benjamin David Lunt Date: Sun, 25 Feb 2024 12:49:51 -0700 Subject: [PATCH 4/6] 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 Message-ID: <000101da6823$ce1bbf80$6a533e80$@fysnet.net> [thuth: Break long line to avoid checkpatch.pl error] Signed-off-by: Thomas Huth --- hw/usb/bus.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/hw/usb/bus.c b/hw/usb/bus.c index 796769fadb..bfab2807d7 100644 --- a/hw/usb/bus.c +++ b/hw/usb/bus.c @@ -260,13 +260,14 @@ static void usb_qdev_realize(DeviceState *qdev, Error **errp) } if (dev->pcap_filename) { - int fd = qemu_open_old(dev->pcap_filename, O_CREAT | O_WRONLY | O_TRUNC, 0666); + int fd = qemu_open_old(dev->pcap_filename, + O_CREAT | O_WRONLY | O_TRUNC | O_BINARY, 0666); if (fd < 0) { error_setg(errp, "open %s failed", dev->pcap_filename); usb_qdev_unrealize(qdev); return; } - dev->pcap = fdopen(fd, "w"); + dev->pcap = fdopen(fd, "wb"); usb_pcap_init(dev->pcap); } } From f0cb6828ae34fb56fbb869bb3147a636d1c984ce Mon Sep 17 00:00:00 2001 From: Thomas Huth Date: Mon, 26 Feb 2024 09:27:28 +0100 Subject: [PATCH 5/6] tests/unit/test-util-sockets: Remove temporary file after test MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Thomas Huth --- tests/unit/test-util-sockets.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/unit/test-util-sockets.c b/tests/unit/test-util-sockets.c index 63909ccb2b..4c9dd0b271 100644 --- a/tests/unit/test-util-sockets.c +++ b/tests/unit/test-util-sockets.c @@ -326,6 +326,7 @@ static void test_socket_unix_abstract(void) test_socket_unix_abstract_row(&matrix[i]); } + unlink(addr.u.q_unix.path); g_free(addr.u.q_unix.path); } From 462945cd22d2bcd233401ed3aa167d83a8e35b05 Mon Sep 17 00:00:00 2001 From: Thomas Huth Date: Thu, 29 Feb 2024 11:43:37 +0100 Subject: [PATCH 6/6] chardev/char-socket: Fix TLS io channels sending too much data to the backend MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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é" Message-ID: <20240229104339.42574-1-thuth@redhat.com> Reviewed-by: Antoine Damhet Tested-by: Antoine Damhet Reviewed-by: Marc-André Lureau Signed-off-by: Thomas Huth --- chardev/char-socket.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/chardev/char-socket.c b/chardev/char-socket.c index 67e3334423..8a0406cc1e 100644 --- a/chardev/char-socket.c +++ b/chardev/char-socket.c @@ -496,9 +496,9 @@ static gboolean tcp_chr_read(QIOChannel *chan, GIOCondition cond, void *opaque) s->max_size <= 0) { return TRUE; } - len = sizeof(buf); - if (len > s->max_size) { - len = s->max_size; + len = tcp_chr_read_poll(opaque); + if (len > sizeof(buf)) { + len = sizeof(buf); } size = tcp_chr_recv(chr, (void *)buf, len); if (size == 0 || (size == -1 && errno != EAGAIN)) {