[PULL 00/13] Misc HW/UI patches for 2024-07-16

[PULL 00/13] Misc HW/UI patches for 2024-07-16

[Philippe Mathieu-Daudé]

The following changes since commit 959269e910944c03bc13f300d65bf08b060d5d0f:

  Merge tag 'python-pull-request' of https://gitlab.com/jsnow/qemu into staging (2024-07-16 06:45:23 +1000)

are available in the Git repository at:

  https://github.com/philmd/qemu.git tags/hw-misc-20240716

for you to fetch changes up to 644a52778a90581dbda909f38b9eaf71501fd9cd:

  system/physmem: use return value of ram_block_discard_require() as errno (2024-07-16 20:04:08 +0200)

Ignored checkpatch error:

  WARNING: line over 80 characters
  #30: FILE: system/vl.c:1004:
  +    if (!ti->class_names[0] || module_object_class_by_name(ti->class_names[0])) {

Ignored CI failures:

 - bios-tables-test on cross-i686-tci
 - qtest-sparc on msys2-64bit

----------------------------------------------------------------
Misc HW & UI patches queue

- Allow loading safely ROMs larger than 4GiB (Gregor)
- Convert vt82c686 IRQ as named 'intr' (Bernhard)
- Clarify QDev GPIO API (Peter)
- Drop unused load_image_gzipped function (Ani)
- Make TCGCPUOps::cpu_exec_interrupt handler mandatory (Peter)
- Factor cpu_pause() out (Nicholas)
- Remove transfer size check from ESP DMA DATA IN / OUT transfers (Mark)
- Add accelerated cursor composition to Cocoa UI (Akihiko)
- Fix '-vga help' CLI (Marc-André)
- Fix displayed errno in ram_block_add (Zhenzhong)

----------------------------------------------------------------

Akihiko Odaki (4):
  ui/cocoa: Release CGColorSpace
  ui/console: Convert mouse visibility parameter into bool
  ui/cocoa: Add cursor composition
  ui/console: Remove dpy_cursor_define_supported()

Ani Sinha (1):
  loader: remove load_image_gzipped function as its not used anywhere

Bernhard Beschow (1):
  hw/isa/vt82c686: Turn "intr" irq into a named gpio

Gregor Haas (1):
  hw/core/loader: allow loading larger ROMs

Marc-André Lureau (1):
  vl: fix "type is NULL" in -vga help

Mark Cave-Ayland (1):
  esp: remove transfer size check from DMA DATA IN and DATA OUT
    transfers

Nicholas Piggin (1):
  system/cpus: Add cpu_pause() function

Peter Maydell (2):
  include/hw/qdev-core.h: Correct and clarify gpio doc comments
  accel/tcg: Make cpu_exec_interrupt hook mandatory

Zhenzhong Duan (1):
  system/physmem: use return value of ram_block_discard_require() as
    errno

 meson.build             |   3 +-
 include/hw/core/cpu.h   |   8 ++++
 include/hw/loader.h     |   4 +-
 include/hw/qdev-core.h  |  17 +++----
 include/ui/console.h    |   5 +-
 accel/tcg/cpu-exec.c    |   4 +-
 hw/core/loader.c        |  45 +++--------------
 hw/display/ati.c        |   2 +-
 hw/display/qxl-render.c |   4 --
 hw/display/virtio-gpu.c |   3 +-
 hw/display/vmware_vga.c |   8 ++--
 hw/isa/vt82c686.c       |   2 +-
 hw/mips/fuloong2e.c     |   2 +-
 hw/ppc/amigaone.c       |   5 +-
 hw/ppc/pegasos2.c       |   4 +-
 hw/scsi/esp.c           |   4 +-
 system/cpus.c           |  30 +++++++-----
 system/physmem.c        |   7 ++-
 system/vl.c             |  13 +++--
 target/tricore/cpu.c    |   6 +++
 ui/console.c            |  18 ++-----
 ui/dbus-listener.c      |   2 +-
 ui/gtk.c                |   2 +-
 ui/sdl2.c               |   4 +-
 ui/spice-display.c      |  11 +++--
 ui/vnc.c                |   2 +-
 ui/cocoa.m              | 104 +++++++++++++++++++++++++++++++++++++++-
 27 files changed, 200 insertions(+), 119 deletions(-)

-- 
2.41.0

[PULL 01/13] hw/core/loader: allow loading larger ROMs

[Philippe Mathieu-Daudé]

From: Gregor Haas <gregorhaas1997@gmail.com>

The read() syscall is not guaranteed to return all data from a file. The
default ROM loader implementation currently does not take this into account,
instead failing if all bytes are not read at once. This change loads the ROM
using g_file_get_contents() instead, which correctly reads all data using
multiple calls to read() while also returning the loaded ROM size.

Signed-off-by: Gregor Haas <gregorhaas1997@gmail.com>
Reviewed-by: Xingtao Yao <yaoxt.fnst@fujitsu.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240628182706.99525-1-gregorhaas1997@gmail.com>
[PMD: Use gsize with g_file_get_contents()]
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 hw/core/loader.c | 32 +++++++-------------------------
 1 file changed, 7 insertions(+), 25 deletions(-)

diff --git a/hw/core/loader.c b/hw/core/loader.c
index a3bea1e718..39bd8f9e4d 100644
--- a/hw/core/loader.c
+++ b/hw/core/loader.c
@@ -1076,8 +1076,8 @@ ssize_t rom_add_file(const char *file, const char *fw_dir,
 {
     MachineClass *mc = MACHINE_GET_CLASS(qdev_get_machine());
     Rom *rom;
-    ssize_t rc;
-    int fd = -1;
+    gsize size;
+    g_autoptr(GError) gerr = NULL;
     char devpath[100];
 
     if (as && mr) {
@@ -1095,10 +1095,10 @@ ssize_t rom_add_file(const char *file, const char *fw_dir,
         rom->path = g_strdup(file);
     }
 
-    fd = open(rom->path, O_RDONLY | O_BINARY);
-    if (fd == -1) {
-        fprintf(stderr, "Could not open option rom '%s': %s\n",
-                rom->path, strerror(errno));
+    if (!g_file_get_contents(rom->path, (gchar **) &rom->data,
+                             &size, &gerr)) {
+        fprintf(stderr, "rom: file %-20s: error %s\n",
+                rom->name, gerr->message);
         goto err;
     }
 
@@ -1107,23 +1107,8 @@ ssize_t rom_add_file(const char *file, const char *fw_dir,
         rom->fw_file = g_strdup(file);
     }
     rom->addr     = addr;
-    rom->romsize  = lseek(fd, 0, SEEK_END);
-    if (rom->romsize == -1) {
-        fprintf(stderr, "rom: file %-20s: get size error: %s\n",
-                rom->name, strerror(errno));
-        goto err;
-    }
-
+    rom->romsize  = size;
     rom->datasize = rom->romsize;
-    rom->data     = g_malloc0(rom->datasize);
-    lseek(fd, 0, SEEK_SET);
-    rc = read(fd, rom->data, rom->datasize);
-    if (rc != rom->datasize) {
-        fprintf(stderr, "rom: file %-20s: read error: rc=%zd (expected %zd)\n",
-                rom->name, rc, rom->datasize);
-        goto err;
-    }
-    close(fd);
     rom_insert(rom);
     if (rom->fw_file && fw_cfg) {
         const char *basename;
@@ -1160,9 +1145,6 @@ ssize_t rom_add_file(const char *file, const char *fw_dir,
     return 0;
 
 err:
-    if (fd != -1)
-        close(fd);
-
     rom_free(rom);
     return -1;
 }
-- 
2.41.0

[PULL 02/13] hw/isa/vt82c686: Turn "intr" irq into a named gpio

[Philippe Mathieu-Daudé]

From: Bernhard Beschow <shentey@gmail.com>

Makes the code more comprehensible, matches the datasheet and
the piix4 device model.

Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240704205854.18537-2-shentey@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 hw/isa/vt82c686.c   | 2 +-
 hw/mips/fuloong2e.c | 2 +-
 hw/ppc/amigaone.c   | 5 +++--
 hw/ppc/pegasos2.c   | 4 ++--
 4 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index 8582ac0322..505b44c4e6 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -719,7 +719,7 @@ static void via_isa_realize(PCIDevice *d, Error **errp)
     ISABus *isa_bus;
     int i;
 
-    qdev_init_gpio_out(dev, &s->cpu_intr, 1);
+    qdev_init_gpio_out_named(dev, &s->cpu_intr, "intr", 1);
     qdev_init_gpio_in_named(dev, via_isa_pirq, "pirq", PCI_NUM_PINS);
     isa_irq = qemu_allocate_irqs(via_isa_request_i8259_irq, s, 1);
     isa_bus = isa_bus_new(dev, pci_address_space(d), pci_address_space_io(d),
diff --git a/hw/mips/fuloong2e.c b/hw/mips/fuloong2e.c
index a45aac368c..6e4303ba47 100644
--- a/hw/mips/fuloong2e.c
+++ b/hw/mips/fuloong2e.c
@@ -299,7 +299,7 @@ static void mips_fuloong2e_init(MachineState *machine)
                               object_resolve_path_component(OBJECT(pci_dev),
                                                             "rtc"),
                               "date");
-    qdev_connect_gpio_out(DEVICE(pci_dev), 0, env->irq[5]);
+    qdev_connect_gpio_out_named(DEVICE(pci_dev), "intr", 0, env->irq[5]);
 
     dev = DEVICE(object_resolve_path_component(OBJECT(pci_dev), "ide"));
     pci_ide_create_devs(PCI_DEVICE(dev));
diff --git a/hw/ppc/amigaone.c b/hw/ppc/amigaone.c
index ddfa09457a..900f93c15e 100644
--- a/hw/ppc/amigaone.c
+++ b/hw/ppc/amigaone.c
@@ -153,8 +153,9 @@ static void amigaone_init(MachineState *machine)
     object_property_add_alias(OBJECT(machine), "rtc-time",
                               object_resolve_path_component(via, "rtc"),
                               "date");
-    qdev_connect_gpio_out(DEVICE(via), 0,
-                          qdev_get_gpio_in(DEVICE(cpu), PPC6xx_INPUT_INT));
+    qdev_connect_gpio_out_named(DEVICE(via), "intr", 0,
+                                qdev_get_gpio_in(DEVICE(cpu),
+                                PPC6xx_INPUT_INT));
     for (i = 0; i < PCI_NUM_PINS; i++) {
         qdev_connect_gpio_out(dev, i, qdev_get_gpio_in_named(DEVICE(via),
                                                              "pirq", i));
diff --git a/hw/ppc/pegasos2.c b/hw/ppc/pegasos2.c
index c1bd8dfa21..9b0a6b70ab 100644
--- a/hw/ppc/pegasos2.c
+++ b/hw/ppc/pegasos2.c
@@ -195,8 +195,8 @@ static void pegasos2_init(MachineState *machine)
     object_property_add_alias(OBJECT(machine), "rtc-time",
                               object_resolve_path_component(via, "rtc"),
                               "date");
-    qdev_connect_gpio_out(DEVICE(via), 0,
-                          qdev_get_gpio_in_named(pm->mv, "gpp", 31));
+    qdev_connect_gpio_out_named(DEVICE(via), "intr", 0,
+                                qdev_get_gpio_in_named(pm->mv, "gpp", 31));
 
     dev = PCI_DEVICE(object_resolve_path_component(via, "ide"));
     pci_ide_create_devs(dev);
-- 
2.41.0

[PULL 03/13] include/hw/qdev-core.h: Correct and clarify gpio doc comments

[Philippe Mathieu-Daudé]

From: Peter Maydell <peter.maydell@linaro.org>

The doc comments for the functions for named GPIO inputs and
outputs had a couple of problems:
 * some copy-and-paste errors meant the qdev_connect_gpio_out_named()
   doc comment had references to input GPIOs that should be to
   output GPIOs
 * it wasn't very clear that named GPIOs are arrays and so the
   connect functions specify a single GPIO line by giving both
   the name of the array and the index within that array

Fix the copy-and-paste errors and slightly expand the text
to say that functions are connecting one line in a named GPIO
array, not a single named GPIO line.

Reported-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240708153312.3109380-1-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 include/hw/qdev-core.h | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index 5336728a23..77bfcbdf73 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -624,8 +624,9 @@ qemu_irq qdev_get_gpio_in(DeviceState *dev, int n);
  * @name: Name of the input GPIO array
  * @n: Number of the GPIO line in that array (which must be in range)
  *
- * Returns the qemu_irq corresponding to a named input GPIO line
- * (which the device has set up with qdev_init_gpio_in_named()).
+ * Returns the qemu_irq corresponding to a single input GPIO line
+ * in a named array of input GPIO lines on a device (which the device
+ * has set up with qdev_init_gpio_in_named()).
  * The @name string must correspond to an input GPIO array which exists on
  * the device, and the index @n of the GPIO line must be valid (i.e.
  * be at least 0 and less than the total number of input GPIOs in that
@@ -673,15 +674,15 @@ void qdev_connect_gpio_out(DeviceState *dev, int n, qemu_irq pin);
  *                              GPIO lines
  * @dev: Device whose GPIO to connect
  * @name: Name of the output GPIO array
- * @n: Number of the anonymous output GPIO line (which must be in range)
+ * @n: Number of the output GPIO line within that array (which must be in range)
  * @input_pin: qemu_irq to connect the output line to
  *
- * This function connects an anonymous output GPIO line on a device
- * up to an arbitrary qemu_irq, so that when the device asserts that
- * output GPIO line, the qemu_irq's callback is invoked.
+ * This function connects a single GPIO output in a named array of output
+ * GPIO lines on a device up to an arbitrary qemu_irq, so that when the
+ * device asserts that output GPIO line, the qemu_irq's callback is invoked.
  * The @name string must correspond to an output GPIO array which exists on
  * the device, and the index @n of the GPIO line must be valid (i.e.
- * be at least 0 and less than the total number of input GPIOs in that
+ * be at least 0 and less than the total number of output GPIOs in that
  * array); this function will assert() if passed an invalid name or index.
  *
  * Outbound GPIO lines can be connected to any qemu_irq, but the common
@@ -796,7 +797,7 @@ void qdev_init_gpio_out(DeviceState *dev, qemu_irq *pins, int n);
  * @dev: Device to create output GPIOs for
  * @pins: Pointer to qemu_irq or qemu_irq array for the GPIO lines
  * @name: Name to give this array of GPIO lines
- * @n: Number of GPIO lines to create
+ * @n: Number of GPIO lines to create in this array
  *
  * Like qdev_init_gpio_out(), but creates an array of GPIO output lines
  * with a name. Code using the device can then connect these GPIO lines
-- 
2.41.0

[PULL 04/13] loader: remove load_image_gzipped function as its not used anywhere

[Philippe Mathieu-Daudé]

From: Ani Sinha <anisinha@redhat.com>

load_image_gzipped() does not seem to be used anywhere. Remove it.

Signed-off-by: Ani Sinha <anisinha@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240711072448.32673-1-anisinha@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 include/hw/loader.h |  4 +---
 hw/core/loader.c    | 13 -------------
 2 files changed, 1 insertion(+), 16 deletions(-)

diff --git a/include/hw/loader.h b/include/hw/loader.h
index 9844c5e3cf..7f6d06b956 100644
--- a/include/hw/loader.h
+++ b/include/hw/loader.h
@@ -77,15 +77,13 @@ ssize_t load_image_targphys(const char *filename, hwaddr,
 ssize_t load_image_mr(const char *filename, MemoryRegion *mr);
 
 /* This is the limit on the maximum uncompressed image size that
- * load_image_gzipped_buffer() and load_image_gzipped() will read. It prevents
+ * load_image_gzipped_buffer() will read. It prevents
  * g_malloc() in those functions from allocating a huge amount of memory.
  */
 #define LOAD_IMAGE_MAX_GUNZIP_BYTES (256 << 20)
 
 ssize_t load_image_gzipped_buffer(const char *filename, uint64_t max_sz,
                                   uint8_t **buffer);
-ssize_t load_image_gzipped(const char *filename, hwaddr addr, uint64_t max_sz);
-
 /**
  * unpack_efi_zboot_image:
  * @buffer: pointer to a variable holding the address of a buffer containing the
diff --git a/hw/core/loader.c b/hw/core/loader.c
index 39bd8f9e4d..31593a1171 100644
--- a/hw/core/loader.c
+++ b/hw/core/loader.c
@@ -845,19 +845,6 @@ ssize_t load_image_gzipped_buffer(const char *filename, uint64_t max_sz,
     return ret;
 }
 
-/* Load a gzip-compressed kernel. */
-ssize_t load_image_gzipped(const char *filename, hwaddr addr, uint64_t max_sz)
-{
-    ssize_t bytes;
-    uint8_t *data;
-
-    bytes = load_image_gzipped_buffer(filename, max_sz, &data);
-    if (bytes != -1) {
-        rom_add_blob_fixed(filename, data, bytes, addr);
-        g_free(data);
-    }
-    return bytes;
-}
 
 /* The PE/COFF MS-DOS stub magic number */
 #define EFI_PE_MSDOS_MAGIC        "MZ"
-- 
2.41.0

[PULL 05/13] accel/tcg: Make cpu_exec_interrupt hook mandatory

[Philippe Mathieu-Daudé]

From: Peter Maydell <peter.maydell@linaro.org>

The TCGCPUOps::cpu_exec_interrupt hook is currently not mandatory; if
it is left NULL then we treat it as if it had returned false. However
since pretty much every architecture needs to handle interrupts,
almost every target we have provides the hook. The one exception is
Tricore, which doesn't currently implement the architectural
interrupt handling.

Add a "do nothing" implementation of cpu_exec_hook for Tricore,
assert on startup that the CPU does provide the hook, and remove
the runtime NULL check before calling it.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20240712113949.4146855-1-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 accel/tcg/cpu-exec.c | 4 ++--
 target/tricore/cpu.c | 6 ++++++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
index 245fd6327d..9010dad073 100644
--- a/accel/tcg/cpu-exec.c
+++ b/accel/tcg/cpu-exec.c
@@ -857,8 +857,7 @@ static inline bool cpu_handle_interrupt(CPUState *cpu,
         else {
             const TCGCPUOps *tcg_ops = cpu->cc->tcg_ops;
 
-            if (tcg_ops->cpu_exec_interrupt &&
-                tcg_ops->cpu_exec_interrupt(cpu, interrupt_request)) {
+            if (tcg_ops->cpu_exec_interrupt(cpu, interrupt_request)) {
                 if (!tcg_ops->need_replay_interrupt ||
                     tcg_ops->need_replay_interrupt(interrupt_request)) {
                     replay_interrupt();
@@ -1080,6 +1079,7 @@ bool tcg_exec_realizefn(CPUState *cpu, Error **errp)
         /* Check mandatory TCGCPUOps handlers */
 #ifndef CONFIG_USER_ONLY
         assert(cpu->cc->tcg_ops->cpu_exec_halt);
+        assert(cpu->cc->tcg_ops->cpu_exec_interrupt);
 #endif /* !CONFIG_USER_ONLY */
         cpu->cc->tcg_ops->initialize();
         tcg_target_initialized = true;
diff --git a/target/tricore/cpu.c b/target/tricore/cpu.c
index 4d9c0368f2..1a26171590 100644
--- a/target/tricore/cpu.c
+++ b/target/tricore/cpu.c
@@ -155,6 +155,11 @@ static void tc37x_initfn(Object *obj)
     set_feature(&cpu->env, TRICORE_FEATURE_162);
 }
 
+static bool tricore_cpu_exec_interrupt(CPUState *cs, int interrupt_request)
+{
+    /* Interrupts are not implemented */
+    return false;
+}
 
 #include "hw/core/sysemu-cpu-ops.h"
 
@@ -169,6 +174,7 @@ static const TCGCPUOps tricore_tcg_ops = {
     .synchronize_from_tb = tricore_cpu_synchronize_from_tb,
     .restore_state_to_opc = tricore_restore_state_to_opc,
     .tlb_fill = tricore_cpu_tlb_fill,
+    .cpu_exec_interrupt = tricore_cpu_exec_interrupt,
     .cpu_exec_halt = tricore_cpu_has_work,
 };
 
-- 
2.41.0

[PULL 06/13] system/cpus: Add cpu_pause() function

[Philippe Mathieu-Daudé]

From: Nicholas Piggin <npiggin@gmail.com>

This factors the CPU pause function from pause_all_vcpus() into a
new cpu_pause() function, similarly to cpu_resume(). cpu_resume()
is moved to keep it next to cpu_pause().

Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Peter Xu <peterx@redhat.com>
Message-ID: <20240712120247.477133-17-npiggin@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 include/hw/core/cpu.h |  8 ++++++++
 system/cpus.c         | 30 +++++++++++++++++-------------
 2 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
index a2c8536943..e6acfcb59a 100644
--- a/include/hw/core/cpu.h
+++ b/include/hw/core/cpu.h
@@ -984,6 +984,14 @@ void cpu_reset_interrupt(CPUState *cpu, int mask);
  */
 void cpu_exit(CPUState *cpu);
 
+/**
+ * cpu_pause:
+ * @cpu: The CPU to pause.
+ *
+ * Pauses CPU, i.e. puts CPU into stopped state.
+ */
+void cpu_pause(CPUState *cpu);
+
 /**
  * cpu_resume:
  * @cpu: The CPU to resume.
diff --git a/system/cpus.c b/system/cpus.c
index d3640c9503..5e3a988a0a 100644
--- a/system/cpus.c
+++ b/system/cpus.c
@@ -568,6 +568,22 @@ void cpu_thread_signal_destroyed(CPUState *cpu)
     qemu_cond_signal(&qemu_cpu_cond);
 }
 
+void cpu_pause(CPUState *cpu)
+{
+    if (qemu_cpu_is_self(cpu)) {
+        qemu_cpu_stop(cpu, true);
+    } else {
+        cpu->stop = true;
+        qemu_cpu_kick(cpu);
+    }
+}
+
+void cpu_resume(CPUState *cpu)
+{
+    cpu->stop = false;
+    cpu->stopped = false;
+    qemu_cpu_kick(cpu);
+}
 
 static bool all_vcpus_paused(void)
 {
@@ -588,12 +604,7 @@ void pause_all_vcpus(void)
 
     qemu_clock_enable(QEMU_CLOCK_VIRTUAL, false);
     CPU_FOREACH(cpu) {
-        if (qemu_cpu_is_self(cpu)) {
-            qemu_cpu_stop(cpu, true);
-        } else {
-            cpu->stop = true;
-            qemu_cpu_kick(cpu);
-        }
+        cpu_pause(cpu);
     }
 
     /* We need to drop the replay_lock so any vCPU threads woken up
@@ -613,13 +624,6 @@ void pause_all_vcpus(void)
     bql_lock();
 }
 
-void cpu_resume(CPUState *cpu)
-{
-    cpu->stop = false;
-    cpu->stopped = false;
-    qemu_cpu_kick(cpu);
-}
-
 void resume_all_vcpus(void)
 {
     CPUState *cpu;
-- 
2.41.0

[PULL 07/13] esp: remove transfer size check from DMA DATA IN and DATA OUT transfers

[Philippe Mathieu-Daudé]

From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>

The transfer size check was originally added to prevent consecutive DMA TI
commands from causing an assert() due to an existing SCSI request being in
progress, but since the last set of updates [*] this is no longer required.

Remove the transfer size check from DMA DATA IN and DATA OUT transfers so
that issuing a DMA TI command when there is no data left to transfer does
not cause an assert() due to an existing SCSI request being in progress.

[*] See commits f3ace75be8..78d68f312a

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2415
Message-ID: <20240713224249.468084-1-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 hw/scsi/esp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
index 5d9b52632e..8504dd30a0 100644
--- a/hw/scsi/esp.c
+++ b/hw/scsi/esp.c
@@ -594,7 +594,7 @@ static void esp_do_dma(ESPState *s)
         if (!s->current_req) {
             return;
         }
-        if (s->async_len == 0 && esp_get_tc(s) && s->ti_size) {
+        if (s->async_len == 0 && esp_get_tc(s)) {
             /* Defer until data is available.  */
             return;
         }
@@ -647,7 +647,7 @@ static void esp_do_dma(ESPState *s)
         if (!s->current_req) {
             return;
         }
-        if (s->async_len == 0 && esp_get_tc(s) && s->ti_size) {
+        if (s->async_len == 0 && esp_get_tc(s)) {
             /* Defer until data is available.  */
             return;
         }
-- 
2.41.0

[PULL 08/13] ui/cocoa: Release CGColorSpace

[Philippe Mathieu-Daudé]

From: Akihiko Odaki <akihiko.odaki@daynix.com>

CGImageCreate | Apple Developer Documentation
https://developer.apple.com/documentation/coregraphics/1455149-cgimagecreate
> The color space is retained; on return, you may safely release it.

Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Tested-by: Phil Dennis-Jordan <phil@philjordan.eu>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240715-cursor-v3-1-afa5b9492dbf@daynix.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 ui/cocoa.m | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 2935247cdd..79a054b128 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -307,6 +307,7 @@ @interface QemuCocoaView : NSView
     BOOL isMouseGrabbed;
     BOOL isAbsoluteEnabled;
     CFMachPortRef eventsTap;
+    CGColorSpaceRef colorspace;
 }
 - (void) switchSurface:(pixman_image_t *)image;
 - (void) grabMouse;
@@ -359,6 +360,7 @@ - (id)initWithFrame:(NSRect)frameRect
         [trackingArea release];
         screen.width = frameRect.size.width;
         screen.height = frameRect.size.height;
+        colorspace = CGColorSpaceCreateWithName(kCGColorSpaceSRGB);
 #if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_VERSION_14_0
         [self setClipsToBounds:YES];
 #endif
@@ -379,6 +381,7 @@ - (void) dealloc
         CFRelease(eventsTap);
     }
 
+    CGColorSpaceRelease(colorspace);
     [super dealloc];
 }
 
@@ -456,7 +459,7 @@ - (void) drawRect:(NSRect) rect
             DIV_ROUND_UP(bitsPerPixel, 8) * 2, //bitsPerComponent
             bitsPerPixel, //bitsPerPixel
             stride, //bytesPerRow
-            CGColorSpaceCreateWithName(kCGColorSpaceSRGB), //colorspace
+            colorspace, //colorspace
             kCGBitmapByteOrder32Little | kCGImageAlphaNoneSkipFirst, //bitmapInfo
             dataProviderRef, //provider
             NULL, //decode
-- 
2.41.0

[PULL 09/13] ui/console: Convert mouse visibility parameter into bool

[Philippe Mathieu-Daudé]

From: Akihiko Odaki <akihiko.odaki@daynix.com>

Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Tested-by: Phil Dennis-Jordan <phil@philjordan.eu>
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240715-cursor-v3-2-afa5b9492dbf@daynix.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 include/ui/console.h    |  4 ++--
 hw/display/ati.c        |  2 +-
 hw/display/virtio-gpu.c |  3 +--
 hw/display/vmware_vga.c |  2 +-
 ui/console.c            |  5 +++--
 ui/dbus-listener.c      |  2 +-
 ui/gtk.c                |  2 +-
 ui/sdl2.c               |  4 ++--
 ui/spice-display.c      | 11 ++++++-----
 ui/vnc.c                |  2 +-
 10 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/include/ui/console.h b/include/ui/console.h
index a208a68b88..82b573e680 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -233,7 +233,7 @@ typedef struct DisplayChangeListenerOps {
 
     /* optional */
     void (*dpy_mouse_set)(DisplayChangeListener *dcl,
-                          int x, int y, int on);
+                          int x, int y, bool on);
     /* optional */
     void (*dpy_cursor_define)(DisplayChangeListener *dcl,
                               QEMUCursor *cursor);
@@ -322,7 +322,7 @@ void dpy_gfx_replace_surface(QemuConsole *con,
 void dpy_text_cursor(QemuConsole *con, int x, int y);
 void dpy_text_update(QemuConsole *con, int x, int y, int w, int h);
 void dpy_text_resize(QemuConsole *con, int w, int h);
-void dpy_mouse_set(QemuConsole *con, int x, int y, int on);
+void dpy_mouse_set(QemuConsole *con, int x, int y, bool on);
 void dpy_cursor_define(QemuConsole *con, QEMUCursor *cursor);
 bool dpy_cursor_define_supported(QemuConsole *con);
 bool dpy_gfx_check_format(QemuConsole *con,
diff --git a/hw/display/ati.c b/hw/display/ati.c
index 8d2501bd82..b1f94f5b76 100644
--- a/hw/display/ati.c
+++ b/hw/display/ati.c
@@ -742,7 +742,7 @@ static void ati_mm_write(void *opaque, hwaddr addr,
         if (!s->cursor_guest_mode &&
             (s->regs.crtc_gen_cntl & CRTC2_CUR_EN) && !(t & BIT(31))) {
             dpy_mouse_set(s->vga.con, s->regs.cur_hv_pos >> 16,
-                          s->regs.cur_hv_pos & 0xffff, 1);
+                          s->regs.cur_hv_pos & 0xffff, true);
         }
         break;
     }
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index d60b1b2973..3281842bfe 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -109,8 +109,7 @@ static void update_cursor(VirtIOGPU *g, struct virtio_gpu_update_cursor *cursor)
         s->cursor.pos.x = cursor->pos.x;
         s->cursor.pos.y = cursor->pos.y;
     }
-    dpy_mouse_set(s->con, cursor->pos.x, cursor->pos.y,
-                  cursor->resource_id ? 1 : 0);
+    dpy_mouse_set(s->con, cursor->pos.x, cursor->pos.y, cursor->resource_id);
 }
 
 struct virtio_gpu_simple_resource *
diff --git a/hw/display/vmware_vga.c b/hw/display/vmware_vga.c
index 1c0f9d9a99..512f224b9f 100644
--- a/hw/display/vmware_vga.c
+++ b/hw/display/vmware_vga.c
@@ -1167,7 +1167,7 @@ static void vmsvga_reset(DeviceState *dev)
     s->enable = 0;
     s->config = 0;
     s->svgaid = SVGA_ID;
-    s->cursor.on = 0;
+    s->cursor.on = false;
     s->redraw_fifo_last = 0;
     s->syncing = 0;
 
diff --git a/ui/console.c b/ui/console.c
index e67c5dae2b..8e9cc1628a 100644
--- a/ui/console.c
+++ b/ui/console.c
@@ -49,7 +49,8 @@ typedef struct QemuGraphicConsole {
     uint32_t head;
 
     QEMUCursor *cursor;
-    int cursor_x, cursor_y, cursor_on;
+    int cursor_x, cursor_y;
+    bool cursor_on;
 } QemuGraphicConsole;
 
 typedef QemuConsoleClass QemuGraphicConsoleClass;
@@ -957,7 +958,7 @@ void dpy_text_resize(QemuConsole *con, int w, int h)
     }
 }
 
-void dpy_mouse_set(QemuConsole *c, int x, int y, int on)
+void dpy_mouse_set(QemuConsole *c, int x, int y, bool on)
 {
     QemuGraphicConsole *con = QEMU_GRAPHIC_CONSOLE(c);
     DisplayState *s = c->ds;
diff --git a/ui/dbus-listener.c b/ui/dbus-listener.c
index 5490088043..a54123acea 100644
--- a/ui/dbus-listener.c
+++ b/ui/dbus-listener.c
@@ -726,7 +726,7 @@ static void dbus_gfx_switch(DisplayChangeListener *dcl,
 }
 
 static void dbus_mouse_set(DisplayChangeListener *dcl,
-                           int x, int y, int on)
+                           int x, int y, bool on)
 {
     DBusDisplayListener *ddl = container_of(dcl, DBusDisplayListener, dcl);
 
diff --git a/ui/gtk.c b/ui/gtk.c
index 93b13b7a30..bc29f7a1b4 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -446,7 +446,7 @@ static GdkDevice *gd_get_pointer(GdkDisplay *dpy)
 }
 
 static void gd_mouse_set(DisplayChangeListener *dcl,
-                         int x, int y, int visible)
+                         int x, int y, bool visible)
 {
     VirtualConsole *vc = container_of(dcl, VirtualConsole, gfx.dcl);
     GdkDisplay *dpy;
diff --git a/ui/sdl2.c b/ui/sdl2.c
index 0a0eb5a42d..98ed974371 100644
--- a/ui/sdl2.c
+++ b/ui/sdl2.c
@@ -49,7 +49,7 @@ static int gui_grab_code = KMOD_LALT | KMOD_LCTRL;
 static SDL_Cursor *sdl_cursor_normal;
 static SDL_Cursor *sdl_cursor_hidden;
 static int absolute_enabled;
-static int guest_cursor;
+static bool guest_cursor;
 static int guest_x, guest_y;
 static SDL_Cursor *guest_sprite;
 static Notifier mouse_mode_notifier;
@@ -729,7 +729,7 @@ void sdl2_poll_events(struct sdl2_console *scon)
 }
 
 static void sdl_mouse_warp(DisplayChangeListener *dcl,
-                           int x, int y, int on)
+                           int x, int y, bool on)
 {
     struct sdl2_console *scon = container_of(dcl, struct sdl2_console, dcl);
 
diff --git a/ui/spice-display.c b/ui/spice-display.c
index 8a8472d029..c794ae0649 100644
--- a/ui/spice-display.c
+++ b/ui/spice-display.c
@@ -254,7 +254,7 @@ static void qemu_spice_create_update(SimpleSpiceDisplay *ssd)
 static SimpleSpiceCursor*
 qemu_spice_create_cursor_update(SimpleSpiceDisplay *ssd,
                                 QEMUCursor *c,
-                                int on)
+                                bool on)
 {
     size_t size = c ? c->width * c->height * 4 : 0;
     SimpleSpiceCursor *update;
@@ -448,7 +448,8 @@ void qemu_spice_display_switch(SimpleSpiceDisplay *ssd,
     qemu_mutex_lock(&ssd->lock);
     if (ssd->cursor) {
         g_free(ssd->ptr_define);
-        ssd->ptr_define = qemu_spice_create_cursor_update(ssd, ssd->cursor, 0);
+        ssd->ptr_define =
+            qemu_spice_create_cursor_update(ssd, ssd->cursor, false);
     }
     qemu_mutex_unlock(&ssd->lock);
 }
@@ -476,7 +477,7 @@ void qemu_spice_cursor_refresh_bh(void *opaque)
         ssd->mouse_x = -1;
         ssd->mouse_y = -1;
         qemu_mutex_unlock(&ssd->lock);
-        dpy_mouse_set(ssd->dcl.con, x, y, 1);
+        dpy_mouse_set(ssd->dcl.con, x, y, true);
     } else {
         qemu_mutex_unlock(&ssd->lock);
     }
@@ -747,7 +748,7 @@ static void display_refresh(DisplayChangeListener *dcl)
 }
 
 static void display_mouse_set(DisplayChangeListener *dcl,
-                              int x, int y, int on)
+                              int x, int y, bool on)
 {
     SimpleSpiceDisplay *ssd = container_of(dcl, SimpleSpiceDisplay, dcl);
 
@@ -774,7 +775,7 @@ static void display_mouse_define(DisplayChangeListener *dcl,
     g_free(ssd->ptr_move);
     ssd->ptr_move = NULL;
     g_free(ssd->ptr_define);
-    ssd->ptr_define = qemu_spice_create_cursor_update(ssd, c, 0);
+    ssd->ptr_define = qemu_spice_create_cursor_update(ssd, c, false);
     qemu_mutex_unlock(&ssd->lock);
     qemu_spice_wakeup(ssd);
 }
diff --git a/ui/vnc.c b/ui/vnc.c
index dd530f04e5..dae5d51210 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -981,7 +981,7 @@ int vnc_send_framebuffer_update(VncState *vs, int x, int y, int w, int h)
 }
 
 static void vnc_mouse_set(DisplayChangeListener *dcl,
-                          int x, int y, int visible)
+                          int x, int y, bool visible)
 {
     /* can we ask the client(s) to move the pointer ??? */
 }
-- 
2.41.0

[PULL 10/13] ui/cocoa: Add cursor composition

[Philippe Mathieu-Daudé]

From: Akihiko Odaki <akihiko.odaki@daynix.com>

Add accelerated cursor composition to ui/cocoa. This does not only
improve performance for display devices that exposes the capability to
the guest according to dpy_cursor_define_supported(), but fixes the
cursor display for devices that unconditionally expects the availability
of the capability (e.g., virtio-gpu).

The common pattern to implement accelerated cursor composition is to
replace the cursor and warp it so that the replaced cursor is shown at
the correct position on the guest display for relative pointer devices.
Unfortunately, ui/cocoa cannot do the same because warping the cursor
position interfers with the mouse input so it uses CALayer instead;
although it is not specialized for cursor composition, it still can
compose images with hardware acceleration.

Co-authored-by: Phil Dennis-Jordan <phil@philjordan.eu>
Tested-by: Phil Dennis-Jordan <phil@philjordan.eu>
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20240715-cursor-v3-3-afa5b9492dbf@daynix.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 meson.build |  3 +-
 ui/cocoa.m  | 99 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 101 insertions(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 6a93da48e1..a1e51277b0 100644
--- a/meson.build
+++ b/meson.build
@@ -1070,7 +1070,8 @@ if get_option('attr').allowed()
   endif
 endif
 
-cocoa = dependency('appleframeworks', modules: ['Cocoa', 'CoreVideo'],
+cocoa = dependency('appleframeworks',
+                   modules: ['Cocoa', 'CoreVideo', 'QuartzCore'],
                    required: get_option('cocoa'))
 
 vmnet = dependency('appleframeworks', modules: 'vmnet', required: get_option('vmnet'))
diff --git a/ui/cocoa.m b/ui/cocoa.m
index 79a054b128..4c2dd33532 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -25,6 +25,7 @@
 #include "qemu/osdep.h"
 
 #import <Cocoa/Cocoa.h>
+#import <QuartzCore/QuartzCore.h>
 #include <crt_externs.h>
 
 #include "qemu/help-texts.h"
@@ -79,12 +80,16 @@ static void cocoa_switch(DisplayChangeListener *dcl,
                          DisplaySurface *surface);
 
 static void cocoa_refresh(DisplayChangeListener *dcl);
+static void cocoa_mouse_set(DisplayChangeListener *dcl, int x, int y, bool on);
+static void cocoa_cursor_define(DisplayChangeListener *dcl, QEMUCursor *cursor);
 
 static const DisplayChangeListenerOps dcl_ops = {
     .dpy_name          = "cocoa",
     .dpy_gfx_update = cocoa_update,
     .dpy_gfx_switch = cocoa_switch,
     .dpy_refresh = cocoa_refresh,
+    .dpy_mouse_set = cocoa_mouse_set,
+    .dpy_cursor_define = cocoa_cursor_define,
 };
 static DisplayChangeListener dcl = {
     .ops = &dcl_ops,
@@ -308,6 +313,11 @@ @interface QemuCocoaView : NSView
     BOOL isAbsoluteEnabled;
     CFMachPortRef eventsTap;
     CGColorSpaceRef colorspace;
+    CALayer *cursorLayer;
+    QEMUCursor *cursor;
+    int mouseX;
+    int mouseY;
+    bool mouseOn;
 }
 - (void) switchSurface:(pixman_image_t *)image;
 - (void) grabMouse;
@@ -364,6 +374,12 @@ - (id)initWithFrame:(NSRect)frameRect
 #if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_VERSION_14_0
         [self setClipsToBounds:YES];
 #endif
+        [self setWantsLayer:YES];
+        cursorLayer = [[CALayer alloc] init];
+        [cursorLayer setAnchorPoint:CGPointMake(0, 1)];
+        [cursorLayer setAutoresizingMask:kCALayerMaxXMargin |
+                                         kCALayerMinYMargin];
+        [[self layer] addSublayer:cursorLayer];
 
     }
     return self;
@@ -382,6 +398,8 @@ - (void) dealloc
     }
 
     CGColorSpaceRelease(colorspace);
+    [cursorLayer release];
+    cursor_unref(cursor);
     [super dealloc];
 }
 
@@ -426,6 +444,72 @@ - (void) unhideCursor
     [NSCursor unhide];
 }
 
+- (void)setMouseX:(int)x y:(int)y on:(bool)on
+{
+    CGPoint position;
+
+    mouseX = x;
+    mouseY = y;
+    mouseOn = on;
+
+    position.x = mouseX;
+    position.y = screen.height - mouseY;
+
+    [CATransaction begin];
+    [CATransaction setDisableActions:YES];
+    [cursorLayer setPosition:position];
+    [cursorLayer setHidden:!mouseOn];
+    [CATransaction commit];
+}
+
+- (void)setCursor:(QEMUCursor *)given_cursor
+{
+    CGDataProviderRef provider;
+    CGImageRef image;
+    CGRect bounds = CGRectZero;
+
+    cursor_unref(cursor);
+    cursor = given_cursor;
+
+    if (!cursor) {
+        return;
+    }
+
+    cursor_ref(cursor);
+
+    bounds.size.width = cursor->width;
+    bounds.size.height = cursor->height;
+
+    provider = CGDataProviderCreateWithData(
+        NULL,
+        cursor->data,
+        cursor->width * cursor->height * 4,
+        NULL
+    );
+
+    image = CGImageCreate(
+        cursor->width, //width
+        cursor->height, //height
+        8, //bitsPerComponent
+        32, //bitsPerPixel
+        cursor->width * 4, //bytesPerRow
+        colorspace, //colorspace
+        kCGBitmapByteOrder32Little | kCGImageAlphaFirst, //bitmapInfo
+        provider, //provider
+        NULL, //decode
+        0, //interpolate
+        kCGRenderingIntentDefault //intent
+    );
+
+    CGDataProviderRelease(provider);
+    [CATransaction begin];
+    [CATransaction setDisableActions:YES];
+    [cursorLayer setBounds:bounds];
+    [cursorLayer setContents:(id)image];
+    [CATransaction commit];
+    CGImageRelease(image);
+}
+
 - (void) drawRect:(NSRect) rect
 {
     COCOA_DEBUG("QemuCocoaView: drawRect\n");
@@ -2015,6 +2099,21 @@ static void cocoa_refresh(DisplayChangeListener *dcl)
     [pool release];
 }
 
+static void cocoa_mouse_set(DisplayChangeListener *dcl, int x, int y, bool on)
+{
+    dispatch_async(dispatch_get_main_queue(), ^{
+        [cocoaView setMouseX:x y:y on:on];
+    });
+}
+
+static void cocoa_cursor_define(DisplayChangeListener *dcl, QEMUCursor *cursor)
+{
+    dispatch_async(dispatch_get_main_queue(), ^{
+        BQL_LOCK_GUARD();
+        [cocoaView setCursor:qemu_console_get_cursor(dcl->con)];
+    });
+}
+
 static void cocoa_display_init(DisplayState *ds, DisplayOptions *opts)
 {
     NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
-- 
2.41.0

[PULL 11/13] ui/console: Remove dpy_cursor_define_supported()

[Philippe Mathieu-Daudé]

From: Akihiko Odaki <akihiko.odaki@daynix.com>

Remove dpy_cursor_define_supported() as it brings no benefit today and
it has a few inherent problems.

All graphical displays except egl-headless support cursor composition
without DMA-BUF, and egl-headless is meant to be used in conjunction
with another graphical display, so dpy_cursor_define_supported()
always returns true and meaningless.

Even if we add a new display without cursor composition in the future,
dpy_cursor_define_supported() will be problematic as a cursor display
fix for it because some display devices like virtio-gpu cannot tell the
lack of cursor composition capability to the guest and are unable to
utilize the value the function returns. Therefore, all non-headless
graphical displays must actually implement cursor composition for
correct cursor display.

Another problem with dpy_cursor_define_supported() is that it returns
true even if only some of the display listeners support cursor
composition, which is wrong unless all display listeners that lack
cursor composition is headless.

Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Phil Dennis-Jordan <phil@philjordan.eu>
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20240715-cursor-v3-4-afa5b9492dbf@daynix.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 include/ui/console.h    |  1 -
 hw/display/qxl-render.c |  4 ----
 hw/display/vmware_vga.c |  6 ++----
 ui/console.c            | 13 -------------
 4 files changed, 2 insertions(+), 22 deletions(-)

diff --git a/include/ui/console.h b/include/ui/console.h
index 82b573e680..fa986ab97e 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -324,7 +324,6 @@ void dpy_text_update(QemuConsole *con, int x, int y, int w, int h);
 void dpy_text_resize(QemuConsole *con, int w, int h);
 void dpy_mouse_set(QemuConsole *con, int x, int y, bool on);
 void dpy_cursor_define(QemuConsole *con, QEMUCursor *cursor);
-bool dpy_cursor_define_supported(QemuConsole *con);
 bool dpy_gfx_check_format(QemuConsole *con,
                           pixman_format_code_t format);
 
diff --git a/hw/display/qxl-render.c b/hw/display/qxl-render.c
index 8daae72c8d..335d01edde 100644
--- a/hw/display/qxl-render.c
+++ b/hw/display/qxl-render.c
@@ -307,10 +307,6 @@ int qxl_render_cursor(PCIQXLDevice *qxl, QXLCommandExt *ext)
         return 1;
     }
 
-    if (!dpy_cursor_define_supported(qxl->vga.con)) {
-        return 0;
-    }
-
     if (qxl->debug > 1 && cmd->type != QXL_CURSOR_MOVE) {
         fprintf(stderr, "%s", __func__);
         qxl_log_cmd_cursor(qxl, cmd, ext->group_id);
diff --git a/hw/display/vmware_vga.c b/hw/display/vmware_vga.c
index 512f224b9f..3db3ff98f7 100644
--- a/hw/display/vmware_vga.c
+++ b/hw/display/vmware_vga.c
@@ -904,10 +904,8 @@ static uint32_t vmsvga_value_read(void *opaque, uint32_t address)
         caps |= SVGA_CAP_RECT_FILL;
 #endif
 #ifdef HW_MOUSE_ACCEL
-        if (dpy_cursor_define_supported(s->vga.con)) {
-            caps |= SVGA_CAP_CURSOR | SVGA_CAP_CURSOR_BYPASS_2 |
-                    SVGA_CAP_CURSOR_BYPASS;
-        }
+        caps |= SVGA_CAP_CURSOR | SVGA_CAP_CURSOR_BYPASS_2 |
+                SVGA_CAP_CURSOR_BYPASS;
 #endif
         ret = caps;
         break;
diff --git a/ui/console.c b/ui/console.c
index 8e9cc1628a..e8f0083af7 100644
--- a/ui/console.c
+++ b/ui/console.c
@@ -1001,19 +1001,6 @@ void dpy_cursor_define(QemuConsole *c, QEMUCursor *cursor)
     }
 }
 
-bool dpy_cursor_define_supported(QemuConsole *con)
-{
-    DisplayState *s = con->ds;
-    DisplayChangeListener *dcl;
-
-    QLIST_FOREACH(dcl, &s->listeners, next) {
-        if (dcl->ops->dpy_cursor_define) {
-            return true;
-        }
-    }
-    return false;
-}
-
 QEMUGLContext dpy_gl_ctx_create(QemuConsole *con,
                                 struct QEMUGLParams *qparams)
 {
-- 
2.41.0

[PULL 12/13] vl: fix "type is NULL" in -vga help

[Philippe Mathieu-Daudé]

From: Marc-André Lureau <marcandre.lureau@redhat.com>

Don't pass NULL to module_object_class_by_name(), when the interface is
unavailable.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240715114420.2062870-1-marcandre.lureau@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 system/vl.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/system/vl.c b/system/vl.c
index bdd2f6ecf6..9e8f16f155 100644
--- a/system/vl.c
+++ b/system/vl.c
@@ -1000,9 +1000,16 @@ static bool vga_interface_available(VGAInterfaceType t)
     const VGAInterfaceInfo *ti = &vga_interfaces[t];
 
     assert(t < VGA_TYPE_MAX);
-    return !ti->class_names[0] ||
-           module_object_class_by_name(ti->class_names[0]) ||
-           module_object_class_by_name(ti->class_names[1]);
+
+    if (!ti->class_names[0] || module_object_class_by_name(ti->class_names[0])) {
+        return true;
+    }
+
+    if (ti->class_names[1] && module_object_class_by_name(ti->class_names[1])) {
+        return true;
+    }
+
+    return false;
 }
 
 static const char *
-- 
2.41.0

[PULL 13/13] system/physmem: use return value of ram_block_discard_require() as errno

[Philippe Mathieu-Daudé]

From: Zhenzhong Duan <zhenzhong.duan@intel.com>

When ram_block_discard_require() fails, errno is passed to error_setg_errno().
It's a stale value or 0 which is unrelated to ram_block_discard_require().

As ram_block_discard_require() already returns -EBUSY in failure case,
use it as errno for error_setg_errno().

Fixes: 852f0048f3ea ("make guest_memfd require uncoordinated discard")
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: David Hildenbrand <david@redhat.com>
Message-ID: <20240716064213.290696-1-zhenzhong.duan@intel.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 system/physmem.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/system/physmem.c b/system/physmem.c
index 2154432cb6..9a3b3a7636 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -1845,11 +1845,14 @@ static void ram_block_add(RAMBlock *new_block, Error **errp)
     }
 
     if (new_block->flags & RAM_GUEST_MEMFD) {
+        int ret;
+
         assert(kvm_enabled());
         assert(new_block->guest_memfd < 0);
 
-        if (ram_block_discard_require(true) < 0) {
-            error_setg_errno(errp, errno,
+        ret = ram_block_discard_require(true);
+        if (ret < 0) {
+            error_setg_errno(errp, -ret,
                              "cannot set up private guest memory: discard currently blocked");
             error_append_hint(errp, "Are you using assigned devices?\n");
             goto out_free;
-- 
2.41.0

Re: [PULL 00/13] Misc HW/UI patches for 2024-07-16

[Richard Henderson]

On 7/17/24 04:09, Philippe Mathieu-Daudé wrote:
> The following changes since commit 959269e910944c03bc13f300d65bf08b060d5d0f:
> 
>    Merge tag 'python-pull-request' ofhttps://gitlab.com/jsnow/qemu into staging (2024-07-16 06:45:23 +1000)
> 
> are available in the Git repository at:
> 
>    https://github.com/philmd/qemu.git tags/hw-misc-20240716
> 
> for you to fetch changes up to 644a52778a90581dbda909f38b9eaf71501fd9cd:
> 
>    system/physmem: use return value of ram_block_discard_require() as errno (2024-07-16 20:04:08 +0200)
> 
> Ignored checkpatch error:
> 
>    WARNING: line over 80 characters
>    #30: FILE: system/vl.c:1004:
>    +    if (!ti->class_names[0] || module_object_class_by_name(ti->class_names[0])) {
> 
> Ignored CI failures:
> 
>   - bios-tables-test on cross-i686-tci
>   - qtest-sparc on msys2-64bit
> 
> ----------------------------------------------------------------
> Misc HW & UI patches queue
> 
> - Allow loading safely ROMs larger than 4GiB (Gregor)
> - Convert vt82c686 IRQ as named 'intr' (Bernhard)
> - Clarify QDev GPIO API (Peter)
> - Drop unused load_image_gzipped function (Ani)
> - MakeTCGCPUOps::cpu_exec_interrupt handler mandatory (Peter)
> - Factor cpu_pause() out (Nicholas)
> - Remove transfer size check from ESP DMA DATA IN / OUT transfers (Mark)
> - Add accelerated cursor composition to Cocoa UI (Akihiko)
> - Fix '-vga help' CLI (Marc-André)
> - Fix displayed errno in ram_block_add (Zhenzhong)

Applied, thanks.

r~

Re: [PULL 11/13] ui/console: Remove dpy_cursor_define_supported()

[Michael Tokarev]

16.07.2024 21:09, Philippe Mathieu-Daudé wrote:
> From: Akihiko Odaki <akihiko.odaki@daynix.com>
> 
> Remove dpy_cursor_define_supported() as it brings no benefit today and
> it has a few inherent problems.
> 
> All graphical displays except egl-headless support cursor composition
> without DMA-BUF, and egl-headless is meant to be used in conjunction
> with another graphical display, so dpy_cursor_define_supported()
> always returns true and meaningless.
> 
> Even if we add a new display without cursor composition in the future,
> dpy_cursor_define_supported() will be problematic as a cursor display
> fix for it because some display devices like virtio-gpu cannot tell the
> lack of cursor composition capability to the guest and are unable to
> utilize the value the function returns. Therefore, all non-headless
> graphical displays must actually implement cursor composition for
> correct cursor display.
> 
> Another problem with dpy_cursor_define_supported() is that it returns
> true even if only some of the display listeners support cursor
> composition, which is wrong unless all display listeners that lack
> cursor composition is headless.

Apparently this commit made windows10 guest to freeze.  There's a rather
hairy bugreport at https://bugs.debian.org/1084199 .  Also there's an
interesting bug filed against qemu, https://gitlab.com/qemu-project/qemu/-/issues/1628 ,
which seems to be relevant.

Can you take a look please?

This user did a great job bisecting qemu with no experience whatsoever..

Thanks,

/mjt

Re: [PULL 11/13] ui/console: Remove dpy_cursor_define_supported()

[Phil Dennis-Jordan]

[-- Attachment #1: Type: text/plain, Size: 5137 bytes --]

On Tue, 29 Oct 2024 at 13:30, Michael Tokarev <mjt@tls.msk.ru> wrote:

> 16.07.2024 21:09, Philippe Mathieu-Daudé wrote:
> > From: Akihiko Odaki <akihiko.odaki@daynix.com>
> >
> > Remove dpy_cursor_define_supported() as it brings no benefit today and
> > it has a few inherent problems.
> >
> > All graphical displays except egl-headless support cursor composition
> > without DMA-BUF, and egl-headless is meant to be used in conjunction
> > with another graphical display, so dpy_cursor_define_supported()
> > always returns true and meaningless.
> >
> > Even if we add a new display without cursor composition in the future,
> > dpy_cursor_define_supported() will be problematic as a cursor display
> > fix for it because some display devices like virtio-gpu cannot tell the
> > lack of cursor composition capability to the guest and are unable to
> > utilize the value the function returns. Therefore, all non-headless
> > graphical displays must actually implement cursor composition for
> > correct cursor display.
> >
> > Another problem with dpy_cursor_define_supported() is that it returns
> > true even if only some of the display listeners support cursor
> > composition, which is wrong unless all display listeners that lack
> > cursor composition is headless.
>
> Apparently this commit made windows10 guest to freeze.  There's a rather
> hairy bugreport at https://bugs.debian.org/1084199 .  Also there's an
> interesting bug filed against qemu,
> https://gitlab.com/qemu-project/qemu/-/issues/1628 ,
> which seems to be relevant.
>
> Can you take a look please?
>
> This user did a great job bisecting qemu with no experience whatsoever..
>
>
It seems an odd commit to be causing this, but you never know… Some random
thoughts on this and a few questions:



As far as I can tell, in both cases the guest display adapter is QXL. In
the case of the Debian user, I think the UI backend is SPICE? Presumably
the it's the same for the user reporting the bug directly against Qemu, as
they also seem to be using libvirt. (No full command line available as far
as I can see?) In any case, the SPICE display specifies:

    .dpy_cursor_define       = display_mouse_define,

Which means the old dpy_cursor_define_supported() would have been returning
true prior to this commit, with the modified QXL and VMSvga code paths
theoretically unaffected. A bit odd, to say the least.

But I suppose it's possible that my understanding is incorrect, and
dpy_cursor_define_supported() might have returned false. The code in
qxl_render_cursor that follows this check and which will now always run, vs
would not have done previously includes:

    if (qxl->debug > 1 && cmd->type != QXL_CURSOR_MOVE) {
        fprintf(stderr, "%s", __func__);
        qxl_log_cmd_cursor(qxl, cmd, ext->group_id);
        fprintf(stderr, "\n");
    }

Can we get the user to set qxl->debug to a value > 1 and see if the freeze
coincides with logging from here? (Possibly tricky to intercept the fprintf
output from Qemu run via libvirt though.)

I also notice that the subsequent code in the QXL_CURSOR_SET case looks a
lot like the code being replaced by Michael's patch from the Qemu bug
tracker. (qxl_phys2virt calls) It looks OK to me, but I'm not familiar with
QXL at all, so perhaps a chunk of code that could use another review?


Or could it be a timing-dependent bug? Although the removed check should
have been rather cheap and shouldn't affect timing much:
- if (!dpy_cursor_define_supported(qxl->vga.con)) {
-        return 0;
-    }



Given that "The time before the freeze seems to be random, from a few
seconds to a couple of minutes." there is a possibility of a false
negative during the bisect. (i.e. commit marked GOOD that should be BAD
because it happened to not hit the freeze in the usual time) If that was
the case, we would expect the regression to be caused by a nearby *earlier*
commit. The only candidate I can spot that touches SPICE or QXL or the
display subsystem in general is a418e7a (ui/console: Convert mouse
visibility parameter into bool) from the same patchset which looks even
more benign, however.



We could ask the user to check whether there's any connection with mouse
cursor changes, e.g. whether he can more easily provoke the issue by
perform actions that rapidly change the mouse cursor. (For example by
visiting https://developer.mozilla.org/en-US/docs/Web/CSS/cursor in the
guest and moving back and forth over the test area.)


Is there an easy way to take a sampling profile on Linux that will show us
stack traces of all the threads in the frozen Qemu process? On macOS this
is easy with the Activity Monitor GUI or iprofiler on the command line.
That ought to confirm whether it's a deadlock or indefinite wait in some
Qemu subsystem.


Michael, what's the situation with the patch you suggested in your comment
on the Qemu bug:
https://gitlab.com/qemu-project/qemu/-/issues/1628#note_2144606625 ? Is
there any chance we can get the Debian user to try that?



Hope that helps!
Phil

[-- Attachment #2: Type: text/html, Size: 6595 bytes --]

Re: [PULL 11/13] ui/console: Remove dpy_cursor_define_supported()

[Michael Weiser]

Hello Hank, Michael, Phil,

> > > Remove dpy_cursor_define_supported() as it brings no benefit today and
> > > it has a few inherent problems.

commit 4bba839808bb1c4f500a11462220a687b4d9ab25
Author: Akihiko Odaki <akihiko.odaki@daynix.com>
Date:   Mon Jul 15 14:25:45 2024 +0900

    ui/console: Remove dpy_cursor_define_supported()

> > Apparently this commit made windows10 guest to freeze.  There's a rather
> > hairy bugreport at https://bugs.debian.org/1084199 .  Also there's an
> > interesting bug filed against qemu,
> > https://gitlab.com/qemu-project/qemu/-/issues/1628 ,
> > which seems to be relevant.

Thanks for looking into this! I am now also affected by this bug and
highly motivated to resolve it. :)

I recently updated my Gentoo Linux system which included an update of
qemu from 9.0.2 to 9.2.0. After that I began to experience the issue
reported by Hank with a Windows 10 VM in libvirt using QXL graphics with
SPICE in virt-viewer. The Windows is fully updated and I've tried
installing the most recent guest drivers to no avail
(virtio-win-0.1.266.iso).

I've reconfirmed the issue with a freshly installed Windows 11, fully
updated and the same driver ISO.

Downgrading to 9.0.4 makes it go away. Downgrading to 9.1.2 does not.
Reverting above commit off of 9.2.0 as a custom patch to the Gentoo
package makes it go away as well.

At this point I grabbed the git repo and started another bisect between
9.0.0 and 9.1.0. During that I found a good "reproducer" to be to
frantically click on all the application icons on my desktop as fast as
possible (Firefox, Edge, LibreOffice, Chrome and PuTTY, FWIW). Apart
from a lot of CPU load, disk I/O and memory pressure it also causes
frequent cursor changes from pointer to spinning wheel to pointer with
spinning wheel. If nothing else, it helps pass the time to the freeze.
:)

With that I ended up at exactly the same commit as Hank found above.
Reverting that commit off of current devel HEAD makes the problem go
away as well. With vanilla devel HEAD the freezes persist/come back.

I can also confirm that the issue has to do with scaling of Windows UI
elements. At 100% the freezes to not appear (or at least not so I can
trigger them with my "reproducer"). At 150% or 200% scaling I can
trigger them quite quickly (< 30s).

Also, identically to Hank's findings, the VM continues to respond to
ICMP requests (ping) as well as agent requests from virsh (e.g.
guestinfo). A shutdown command however hangs/times out.

On Tue, Oct 29, 2024 at 03:04:29PM +0100, Phil Dennis-Jordan wrote:

> Can we get the user to set qxl->debug to a value > 1 and see if the freeze
> coincides with logging from here? (Possibly tricky to intercept the fprintf
> output from Qemu run via libvirt though.)

How would I do that? On the source level or is there an environment
variable/command line option?

> Given that "The time before the freeze seems to be random, from a few
> seconds to a couple of minutes." there is a possibility of a false
> negative during the bisect. (i.e. commit marked GOOD that should be BAD
> because it happened to not hit the freeze in the usual time)

I went to the commit before this one and the issue disappeared. Also the
positive effect of reverting it off of HEAD seems to suggest that if not
the main culprit it at least makes the possibly underlying issue
surface.

> We could ask the user to check whether there's any connection with mouse
> cursor changes, e.g. whether he can more easily provoke the issue by
> perform actions that rapidly change the mouse cursor. (For example by
> visiting https://developer.mozilla.org/en-US/docs/Web/CSS/cursor in the
> guest and moving back and forth over the test area.)

I've extracted the IFrame URL
https://interactive-examples.mdn.mozilla.net/pages/css/cursor.html from
this and played with it for some time.

On an idling system the cursor changes do not seem to be enough to
trigger the issue. Once I start to put load on the system by starting
applications as per my "reproducer" I can no longer be sure if and how
cursor changes play into it because lots of windows start popping up.
All hangs I can remember have been showing the segmented spinning blue
wheel animated cursor though.

> Is there an easy way to take a sampling profile on Linux that will show us
> stack traces of all the threads in the frozen Qemu process? On macOS this
> is easy with the Activity Monitor GUI or iprofiler on the command line.
> That ought to confirm whether it's a deadlock or indefinite wait in some
> Qemu subsystem.

The stuck qemu still does things at about 3% CPU load.
I can attach to it with gdb and pull the thread list below.
Do any of those look interesting to you?

(gdb) info threads
  Id   Target Id                                            Frame 
* 1    Thread 0x7f0eada740c0 (LWP 741887) "qemu-system-x86" 0x00007f0eaf73e656 in ppoll () from /usr/lib64/libc.so.6
  2    Thread 0x7f0ccdffb6c0 (LWP 742004) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
  3    Thread 0x7f0cceffd6c0 (LWP 742002) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
  4    Thread 0x7f0ced7fa6c0 (LWP 741998) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
  5    Thread 0x7f0cee7fc6c0 (LWP 741996) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
  6    Thread 0x7f0ceffff6c0 (LWP 741993) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
  7    Thread 0x7f0d0d7fa6c0 (LWP 741991) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
  8    Thread 0x7f0d0e7fc6c0 (LWP 741989) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
  9    Thread 0x7f0d0f7fe6c0 (LWP 741987) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
  10   Thread 0x7f0d2d7fa6c0 (LWP 741984) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
  11   Thread 0x7f0d2f7fe6c0 (LWP 741980) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
  12   Thread 0x7f0d2ffff6c0 (LWP 741917) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
  13   Thread 0x7f0d514f76c0 (LWP 741915) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
  14   Thread 0x7f0d52cfa6c0 (LWP 741912) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
  15   Thread 0x7f0d534fb6c0 (LWP 741911) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
  16   Thread 0x7f0d53cfc6c0 (LWP 741910) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
  17   Thread 0x7f0d591986c0 (LWP 741905) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
  18   Thread 0x7f0d6531e6c0 (LWP 741902) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
  19   Thread 0x7f0d9afff6c0 (LWP 741900) "SPICE Worker"    0x00007f0eaf73e656 in ppoll () from /usr/lib64/libc.so.6
  20   Thread 0x7f0ea89ff6c0 (LWP 741898) "CPU 1/KVM"       0x00007f0eaf74534f in ioctl () from /usr/lib64/libc.so.6
  21   Thread 0x7f0ea95a96c0 (LWP 741897) "CPU 0/KVM"       0x00007f0eaf74534f in ioctl () from /usr/lib64/libc.so.6
  22   Thread 0x7f0ea9daa6c0 (LWP 741896) "IO mon_iothread" 0x00007f0eaf73e656 in ppoll () from /usr/lib64/libc.so.6
  23   Thread 0x7f0eada740c0 (LWP 741895) "vhost-741887"    0x0000000000000000 in ?? ()
  24   Thread 0x7f0eada740c0 (LWP 741894) "kvm-nx-lpage-re" 0x0000000000000000 in ?? ()
  25   Thread 0x7f0eab8356c0 (LWP 741892) "qemu-system-x86" 0x00007f0eaf74776d in syscall () from /usr/lib64/libc.so.6

This is right after the display gets stuck. The workers die down over time.

> Michael, what's the situation with the patch you suggested in your comment
> on the Qemu bug:
> https://gitlab.com/qemu-project/qemu/-/issues/1628#note_2144606625 ? Is
> there any chance we can get the Debian user to try that?

This patch on top of current devel HEAD (as well as directly on top of
the commit in question) makes it worse: The freezes start happening
immediately after the desktop shell is started. I think I've even seen it
freeze when the boot logo and spinner were still showing, possibly when
the (also scaled) login screen tries to initialise.

I'm out of my depth further narrowing down the cause and standing by to
try whatever you tell me.
-- 
Thanks,
Michael

Re: [PULL 11/13] ui/console: Remove dpy_cursor_define_supported()

[Hank Knox]

Dear Michael W et al,

Thank you for following up on this. While waiting for a fix, I have been 
using a build I made myself that applies the patch listed at the bottom 
of this email to the v9.2.0 branch of the code (which has  
dpy_cursor_define_supported() removed) and it has been working fine ever 
since. I also have the display scaled to 150%. I don't have any other 
insights or clues into causes or fixes.

Since I last responded to the bug report I filed on the Debian bug 
tracker (#1084199), I have read on the Debian User Forums (where I also 
went looking for help) that several other people are having trouble with 
this issue. They found, like you did, that reverting to 9.0.2 fixed the 
problem. You can find the thread at 
https://forums.debian.net/viewtopic.php?t=160631 but I don't see any new 
clues there.

I also am very happy to test any possible patches and to gather any 
other information, to the limits of my tech ability.

Best,

Hank


On 1/9/25 08:58, Michael Weiser wrote:
> Hello Hank, Michael, Phil,
>
>>>> Remove dpy_cursor_define_supported() as it brings no benefit today and
>>>> it has a few inherent problems.
> commit 4bba839808bb1c4f500a11462220a687b4d9ab25
> Author: Akihiko Odaki <akihiko.odaki@daynix.com>
> Date:   Mon Jul 15 14:25:45 2024 +0900
>
>      ui/console: Remove dpy_cursor_define_supported()
>
>>> Apparently this commit made windows10 guest to freeze.  There's a rather
>>> hairy bugreport at https://bugs.debian.org/1084199 .  Also there's an
>>> interesting bug filed against qemu,
>>> https://gitlab.com/qemu-project/qemu/-/issues/1628 ,
>>> which seems to be relevant.
> Thanks for looking into this! I am now also affected by this bug and
> highly motivated to resolve it. :)
>
> I recently updated my Gentoo Linux system which included an update of
> qemu from 9.0.2 to 9.2.0. After that I began to experience the issue
> reported by Hank with a Windows 10 VM in libvirt using QXL graphics with
> SPICE in virt-viewer. The Windows is fully updated and I've tried
> installing the most recent guest drivers to no avail
> (virtio-win-0.1.266.iso).
>
> I've reconfirmed the issue with a freshly installed Windows 11, fully
> updated and the same driver ISO.
>
> Downgrading to 9.0.4 makes it go away. Downgrading to 9.1.2 does not.
> Reverting above commit off of 9.2.0 as a custom patch to the Gentoo
> package makes it go away as well.
>
> At this point I grabbed the git repo and started another bisect between
> 9.0.0 and 9.1.0. During that I found a good "reproducer" to be to
> frantically click on all the application icons on my desktop as fast as
> possible (Firefox, Edge, LibreOffice, Chrome and PuTTY, FWIW). Apart
> from a lot of CPU load, disk I/O and memory pressure it also causes
> frequent cursor changes from pointer to spinning wheel to pointer with
> spinning wheel. If nothing else, it helps pass the time to the freeze.
> :)
>
> With that I ended up at exactly the same commit as Hank found above.
> Reverting that commit off of current devel HEAD makes the problem go
> away as well. With vanilla devel HEAD the freezes persist/come back.
>
> I can also confirm that the issue has to do with scaling of Windows UI
> elements. At 100% the freezes to not appear (or at least not so I can
> trigger them with my "reproducer"). At 150% or 200% scaling I can
> trigger them quite quickly (< 30s).
>
> Also, identically to Hank's findings, the VM continues to respond to
> ICMP requests (ping) as well as agent requests from virsh (e.g.
> guestinfo). A shutdown command however hangs/times out.
>
> On Tue, Oct 29, 2024 at 03:04:29PM +0100, Phil Dennis-Jordan wrote:
>
>> Can we get the user to set qxl->debug to a value > 1 and see if the freeze
>> coincides with logging from here? (Possibly tricky to intercept the fprintf
>> output from Qemu run via libvirt though.)
> How would I do that? On the source level or is there an environment
> variable/command line option?
>
>> Given that "The time before the freeze seems to be random, from a few
>> seconds to a couple of minutes." there is a possibility of a false
>> negative during the bisect. (i.e. commit marked GOOD that should be BAD
>> because it happened to not hit the freeze in the usual time)
> I went to the commit before this one and the issue disappeared. Also the
> positive effect of reverting it off of HEAD seems to suggest that if not
> the main culprit it at least makes the possibly underlying issue
> surface.
>
>> We could ask the user to check whether there's any connection with mouse
>> cursor changes, e.g. whether he can more easily provoke the issue by
>> perform actions that rapidly change the mouse cursor. (For example by
>> visiting https://developer.mozilla.org/en-US/docs/Web/CSS/cursor in the
>> guest and moving back and forth over the test area.)
> I've extracted the IFrame URL
> https://interactive-examples.mdn.mozilla.net/pages/css/cursor.html from
> this and played with it for some time.
>
> On an idling system the cursor changes do not seem to be enough to
> trigger the issue. Once I start to put load on the system by starting
> applications as per my "reproducer" I can no longer be sure if and how
> cursor changes play into it because lots of windows start popping up.
> All hangs I can remember have been showing the segmented spinning blue
> wheel animated cursor though.
>
>> Is there an easy way to take a sampling profile on Linux that will show us
>> stack traces of all the threads in the frozen Qemu process? On macOS this
>> is easy with the Activity Monitor GUI or iprofiler on the command line.
>> That ought to confirm whether it's a deadlock or indefinite wait in some
>> Qemu subsystem.
> The stuck qemu still does things at about 3% CPU load.
> I can attach to it with gdb and pull the thread list below.
> Do any of those look interesting to you?
>
> (gdb) info threads
>    Id   Target Id                                            Frame
> * 1    Thread 0x7f0eada740c0 (LWP 741887) "qemu-system-x86" 0x00007f0eaf73e656 in ppoll () from /usr/lib64/libc.so.6
>    2    Thread 0x7f0ccdffb6c0 (LWP 742004) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
>    3    Thread 0x7f0cceffd6c0 (LWP 742002) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
>    4    Thread 0x7f0ced7fa6c0 (LWP 741998) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
>    5    Thread 0x7f0cee7fc6c0 (LWP 741996) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
>    6    Thread 0x7f0ceffff6c0 (LWP 741993) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
>    7    Thread 0x7f0d0d7fa6c0 (LWP 741991) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
>    8    Thread 0x7f0d0e7fc6c0 (LWP 741989) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
>    9    Thread 0x7f0d0f7fe6c0 (LWP 741987) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
>    10   Thread 0x7f0d2d7fa6c0 (LWP 741984) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
>    11   Thread 0x7f0d2f7fe6c0 (LWP 741980) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
>    12   Thread 0x7f0d2ffff6c0 (LWP 741917) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
>    13   Thread 0x7f0d514f76c0 (LWP 741915) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
>    14   Thread 0x7f0d52cfa6c0 (LWP 741912) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
>    15   Thread 0x7f0d534fb6c0 (LWP 741911) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
>    16   Thread 0x7f0d53cfc6c0 (LWP 741910) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
>    17   Thread 0x7f0d591986c0 (LWP 741905) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
>    18   Thread 0x7f0d6531e6c0 (LWP 741902) "worker"          0x00007f0eaf6d785e in ?? () from /usr/lib64/libc.so.6
>    19   Thread 0x7f0d9afff6c0 (LWP 741900) "SPICE Worker"    0x00007f0eaf73e656 in ppoll () from /usr/lib64/libc.so.6
>    20   Thread 0x7f0ea89ff6c0 (LWP 741898) "CPU 1/KVM"       0x00007f0eaf74534f in ioctl () from /usr/lib64/libc.so.6
>    21   Thread 0x7f0ea95a96c0 (LWP 741897) "CPU 0/KVM"       0x00007f0eaf74534f in ioctl () from /usr/lib64/libc.so.6
>    22   Thread 0x7f0ea9daa6c0 (LWP 741896) "IO mon_iothread" 0x00007f0eaf73e656 in ppoll () from /usr/lib64/libc.so.6
>    23   Thread 0x7f0eada740c0 (LWP 741895) "vhost-741887"    0x0000000000000000 in ?? ()
>    24   Thread 0x7f0eada740c0 (LWP 741894) "kvm-nx-lpage-re" 0x0000000000000000 in ?? ()
>    25   Thread 0x7f0eab8356c0 (LWP 741892) "qemu-system-x86" 0x00007f0eaf74776d in syscall () from /usr/lib64/libc.so.6
>
> This is right after the display gets stuck. The workers die down over time.
>
>> Michael, what's the situation with the patch you suggested in your comment
>> on the Qemu bug:
>> https://gitlab.com/qemu-project/qemu/-/issues/1628#note_2144606625 ? Is
>> there any chance we can get the Debian user to try that?
> This patch on top of current devel HEAD (as well as directly on top of
> the commit in question) makes it worse: The freezes start happening
> immediately after the desktop shell is started. I think I've even seen it
> freeze when the boot logo and spinner were still showing, possibly when
> the (also scaled) login screen tries to initialise.
>
> I'm out of my depth further narrowing down the cause and standing by to
> try whatever you tell me.

-- 
Hank Knox, FRSC
Schulich School of Music of
McGill University (retired)
Montreal, QC

Re: [PULL 11/13] ui/console: Remove dpy_cursor_define_supported()

[Michael Weiser]

Hi everyone,

On Thu, Jan 09, 2025 at 09:34:41AM -0500, Hank Knox wrote:

> > commit 4bba839808bb1c4f500a11462220a687b4d9ab25
> > Author: Akihiko Odaki <akihiko.odaki@daynix.com>
> > Date:   Mon Jul 15 14:25:45 2024 +0900
> >
> >      ui/console: Remove dpy_cursor_define_supported()
> >
> > > > Apparently this commit made windows10 guest to freeze.  There's a rather
> > > > hairy bugreport at https://bugs.debian.org/1084199 .  Also there's an
> > > > interesting bug filed against qemu,
> > > > https://gitlab.com/qemu-project/qemu/-/issues/1628 ,
> > > > which seems to be relevant.
> I also am very happy to test any possible patches and to gather any other
> information, to the limits of my tech ability.

I've just run into this again after a system update which brought
qemu-9.2.2 and re-applied the revert locally which again circumvents the
issue for me.

Is there anything I can do to move forward finding a permanent solution?
-- 
Thanks,
Michael