[Qemu-devel] [Bug 1838228] Re: Slirp Broadcast traffic
slirp has been moved to a standalone project, can you report here: https://gitlab.freedesktop.org/slirp/libslirp/issues I don't have an answer off the top of my head, but I would suggest looking/tweaking at the network mask. And for the receive side, debugging from sorecvfrom(). -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1838228 Title: Slirp Broadcast traffic Status in QEMU: New Bug description: Hi all, Version: QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-7+build1) I'm running some DHCP traffic to a *custom* DHCP server with user-mode networking in QEMU. I'm using port 30067 for the server, so this does not conflict with the built-in DHCP server. DHCP broadcasts to and from the server, and I'm observing issues with both sending and receiving packets. Firstly, from the VM, a packet sent to IPv4 x.x.x.2:30067 (gateway) makes it to the server, but a packet sent to 255.255.255.255 does not. I'd suspect that Slirp has to support sending to the broadcast IP address? Or is this something I can turn on with a configuration option? (My QEMU version too old?) Secondly, the source address in a DHCP IPv4 packet must be 0.0.0.0 (by RFC). That means that any return packet will have 0.0.0.0 swapped in as its destination address. However, that packet doesn't make it into the VM at all. I know that if you deliver this packet to Linux, a raw socket will spit it back out. The packets' destination address should not prevent the packet from being delivered to the right VM, since Slirp (should?) know exactly which VM the session belongs to. (It's a proxy, not a router.) WDYT? Did I miss some configuration options or use too old a version? Thanks, Chris To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1838228/+subscriptions
[Qemu-devel] [Bug 1809453] Re: Windows qemu download Big file bug in net user mode
What is your version of qemu? I understand you are running qemu on ubuntu. The VM is windows? which version? Which URL are you downloading? What is the program being used? thanks ** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1809453 Title: Windows qemu download Big file bug in net user mode Status in QEMU: Incomplete Bug description: hi Windows qemu with -net user downloading big files has a bug, -net tap is good! I suspect that the Slirp protocol has a bug on the Windows pc, which is normal on ubuntu. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1809453/+subscriptions
[Qemu-devel] [Bug 1010484] Re: slirp to accept non-local dns server
ping ** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1010484 Title: slirp to accept non-local dns server Status in QEMU: Incomplete Bug description: current version of slirp doesn't allow feeded dns address to be outside of given network. in many scenarios you need to provide dns server that isn't local. this simple patch removes checking for if dns server isn't in local subnet. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1010484/+subscriptions
[Qemu-devel] [Bug 1635339] Re: qxl_pre_save assertion failure on vm "save"
Crash reproduced immediately after setting up a win10 VM with qxl driver 10.0.0.15000. Gerd, are you looking into fixing it? Is it acceptable to crash qemu if the driver is faulty? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1635339 Title: qxl_pre_save assertion failure on vm "save" Status in QEMU: New Bug description: When I try and save my Windows 10 VM, I see an assertion failure, and the machine is shut down. I see the following in the log: main_channel_handle_parsed: agent start qemu-system-x86_64: /build/qemu-Zwynhi/qemu-2.5+dfsg/hw/display/qxl.c:2101: qxl_pre_save: Assertion `d->last_release_offset < d->vga.vram_size' failed. 2016-10-20 11:52:42.713+: shutting down Please let me know what other information would be relevant! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1635339/+subscriptions
[Qemu-devel] [Bug 1635339] Re: qxl_pre_save assertion failure on vm "save"
damn launchpad, wrong bug and I can't change it back. Please someone move it back to New/Confirmed ** Changed in: qemu Status: New => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1635339 Title: qxl_pre_save assertion failure on vm "save" Status in QEMU: Fix Released Bug description: When I try and save my Windows 10 VM, I see an assertion failure, and the machine is shut down. I see the following in the log: main_channel_handle_parsed: agent start qemu-system-x86_64: /build/qemu-Zwynhi/qemu-2.5+dfsg/hw/display/qxl.c:2101: qxl_pre_save: Assertion `d->last_release_offset < d->vga.vram_size' failed. 2016-10-20 11:52:42.713+: shutting down Please let me know what other information would be relevant! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1635339/+subscriptions
[Qemu-devel] [Bug 1020484] Re: RFE: Support spice via unix domain socket
you could pass sockets via QMP a while ago, but listening to unix socket has been added there: commit fe4831b1e7e7007ae15ae0470a06898660ab3877 Author: Marc-André Lureau Date: Tue Jan 13 17:57:51 2015 +0100 spice: add unix address support Teach qemu to set up a Spice server with a UNIX socket using the following arguments -spice unix,addr=path. Signed-off-by: Gerd Hoffmann ** Changed in: qemu Status: New => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1020484 Title: RFE: Support spice via unix domain socket Status in QEMU: Fix Released Bug description: According to the man page, spice can be only used via TCP/IP in opposite to VNC, which can also be configured to listen on a unix domain socket. To make it easy to use spice without exposing the interface, please support unix domain sockets as well. I can try to provide a patch, if you can point me to the source code where TCP/IP socket is opened. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1020484/+subscriptions
[Qemu-devel] [Bug 1635339] Re: qxl_pre_save assertion failure on vm "save"
Your approach works ok Gerd with a migration blocker. Are you going to send a patch? I am afraid we would have to make this code permanent though, since there has been several releases of this driver already, and it's much nicer to block migration than to crash a VM. I have reached out to wddm driver about the bug. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1635339 Title: qxl_pre_save assertion failure on vm "save" Status in QEMU: Confirmed Bug description: When I try and save my Windows 10 VM, I see an assertion failure, and the machine is shut down. I see the following in the log: main_channel_handle_parsed: agent start qemu-system-x86_64: /build/qemu-Zwynhi/qemu-2.5+dfsg/hw/display/qxl.c:2101: qxl_pre_save: Assertion `d->last_release_offset < d->vga.vram_size' failed. 2016-10-20 11:52:42.713+: shutting down Please let me know what other information would be relevant! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1635339/+subscriptions
Re: [Qemu-devel] [Bug 1658634] [PATCH] console: fix console resize
Hi
On Tue, Jan 24, 2017 at 2:31 PM Gerd Hoffmann <1658...@bugs.launchpad.net>
wrote:
> Only skip surface reallocation in case the old surface was created using
> qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we
> might end up with a DisplaySurface with the wrong backing storage.
>
> Cc: 1658...@bugs.launchpad.net
> Cc: Marc-André Lureau
> Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64
> Signed-off-by: Gerd Hoffmann
> ---
> ui/console.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ui/console.c b/ui/console.c
> index b9575f2..67c65b7 100644
> --- a/ui/console.c
> +++ b/ui/console.c
> @@ -2121,7 +2121,7 @@ void qemu_console_resize(QemuConsole *s, int width,
> int height)
>
> assert(s->console_type == GRAPHIC_CONSOLE);
>
> -if (s->surface &&
> +if (s->surface && (surface->flags & QEMU_ALLOCATED_FLAG) &&
> pixman_image_get_width(s->surface->image) == width &&
> pixman_image_get_height(s->surface->image) == height) {
> return;
>
You are missing the 's->' !
with that,
Reviewed-by: Marc-André Lureau
--
> 1.8.3.1
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1658634
>
> Title:
> Can't get correct display with latest QEMU and OVMF BIOS
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1658634/+subscriptions
>
--
Marc-André Lureau
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1658634
Title:
Can't get correct display with latest QEMU and OVMF BIOS
Status in QEMU:
Confirmed
Bug description:
I tried to install a Ubuntu 16.04.1 Desktop 64bits with latest QEMU and OVMF
UEFI BIOS, however I can't get correct display output with default vga
configuration (-vga std). However, qemu works with a couple of different
configurations:
1. "-vga cirrus" + "-bios OVMF.fd": works
2. "-vga std" + non-UEFI bios: works
The same error with QEMU 2.8.0 release. Everything works well on
2.7.0/1.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1658634/+subscriptions
[Qemu-devel] [Bug 1679126] Re: null pointer access on migration resume of systemrescuecd boot menu with qxl-vga
Interesting, the culprit is:
commit cd958edb1fae85d0c7d1e1acbff82d22724e8d64
Author: Marc-André Lureau
Date: Fri Aug 26 13:47:11 2016 +0400
console: skip same-size resize
virtio-gpu does a set-scanout at each frame (it might be a driver
regression). qemu_console_resize() recreate a surface even if the size
didn't change, and this shows up in profiling reports because the
surface is cleared. With this patch, I get a +15-20% glmark2
improvement.
Signed-off-by: Marc-André Lureau
Message-id: 20160826094711.14470-1-marcandre.lur...@redhat.com
Signed-off-by: Gerd Hoffmann
diff --git a/ui/console.c b/ui/console.c
index 3940762851..394786b3c7 100644
--- a/ui/console.c
+++ b/ui/console.c
@@ -2101,6 +2101,13 @@ void qemu_console_resize(QemuConsole *s, int width, int
height)
DisplaySurface *surface;
assert(s->console_type == GRAPHIC_CONSOLE);
+
+if (s->surface &&
+pixman_image_get_width(s->surface->image) == width &&
+pixman_image_get_height(s->surface->image) == height) {
+return;
+}
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1679126
Title:
null pointer access on migration resume of systemrescuecd boot menu
with qxl-vga
Status in QEMU:
Confirmed
Bug description:
With qemu-2.8.0 up to 2.9.0-rc2 and git master (6954cdc), when
resuming from a migration state file created from a VM suspended while
showing the System Rescue CD 4.9.2 boot menu and using the QXL VGA
device, I get a null point access in pixman_image_get_data called from
qemu_spice_create_update (spice-display.c:215). When I added
assert(ssd->mirror != NULL) above that line, assert failed. I don't
get the crash when using standard VGA or cirrus-vga. I am using
gcc-4.9.3 on Gentoo x86_64 with Intel i7-4700HQ CPU and kernel:
4.9.15-gentoo.
Here is the valgrind trace from the git version:
==2634== Thread 1:
==2634== Invalid read of size 4
==3516==at 0x65F3050: pixman_image_get_data (in
/usr/lib64/libpixman-1.so.0.34.0)
==3516==by 0x6F0CEB: qemu_spice_create_update (spice-display.c:215)
==3516==by 0x6F1CC7: qemu_spice_display_refresh (spice-display.c:502)
==3516==by 0x58CF77: display_refresh (qxl.c:1948)
==3516==by 0x6E8084: do_safe_dpy_refresh (console.c:1591)
==3516==by 0x6E80D5: dpy_refresh (console.c:1604)
==3516==by 0x6E4508: gui_update (console.c:201)
==3516==by 0x81898E: timerlist_run_timers (qemu-timer.c:536)
==3516==by 0x8189D6: qemu_clock_run_timers (qemu-timer.c:547)
==3516==by 0x818D98: qemu_clock_run_all_timers (qemu-timer.c:662)
==3516==by 0x81952A: main_loop_wait (main-loop.c:514)
==3516==by 0x4ADD29: main_loop (vl.c:1898)
Minimal steps to reproduce:
Compile (debug compile flags are just so valgrind works, the crash occurs
with non-debug compile flags as well):
CFLAGS="-g -O0" CXXFLAGS="-g -O0" ./configure
--target-list=i386-softmmu,x86_64-softmmu
./configure
make
Start VM and leave it on the System Rescue CD graphical boot menu:
x86_64-softmmu/qemu-system-x86_64 -nodefaults -machine pc -drive
file=systemrescuecd-x86-4.9.2.iso,if=none,id=cdrom-cd,readonly=on -device
ide-cd,bus=ide.0,drive=cdrom-cd,bootindex=1 -device qxl-vga -monitor
unix:monitor.sock,server,nowait -display gtk
Suspend VM and save state:
socat - unix:monitor.sock
stop
migrate "exec:cat > vm.state"
quit
Attempt to resume VM (but this crashes):
x86_64-softmmu/qemu-system-x86_64 -nodefaults -machine pc -drive
file=systemrescuecd-x86-4.9.2.iso,if=none,id=cdrom-cd,readonly=on -device
ide-cd,bus=ide.0,drive=cdrom-cd,bootindex=1 -device qxl-vga -monitor
unix:monitor.sock,server,nowait -display gtk -incoming exec:"cat vm.state"
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1679126/+subscriptions
[Qemu-devel] [Bug 1803872] Re: [PATCH v2 3/3] migration: Replace strncpy() by strpadcpy(pad='\0')
On Tue, Dec 18, 2018 at 3:09 PM Philippe Mathieu-Daudé
wrote:
>
> GCC 8 added a -Wstringop-truncation warning:
>
> The -Wstringop-truncation warning added in GCC 8.0 via r254630 for
> bug 81117 is specifically intended to highlight likely unintended
> uses of the strncpy function that truncate the terminating NUL
> character from the source string.
>
> This new warning leads to compilation failures:
>
> CC migration/global_state.o
> qemu/migration/global_state.c: In function 'global_state_store_running':
> qemu/migration/global_state.c:45:5: error: 'strncpy' specified bound 100
> equals destination size [-Werror=stringop-truncation]
>strncpy((char *)global_state.runstate, state,
> sizeof(global_state.runstate));
>
> ^~~~
> make: *** [qemu/rules.mak:69: migration/global_state.o] Error 1
>
> The runstate name doesn't require the strings to be NUL-terminated,
> therefore strncpy is the right function to use here.
>
> We could add a #pragma GCC diagnostic ignored "-Wstringop-truncation"
> around, disable the warning globally using -Wno-stringop-truncation,
> but since QEMU provides the strpadcpy() which does the same purpose,
> simply use it to avoid the annoying warning.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Marc-André Lureau
> ---
> migration/global_state.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/migration/global_state.c b/migration/global_state.c
> index 8e8ab5c51e..c7e7618118 100644
> --- a/migration/global_state.c
> +++ b/migration/global_state.c
> @@ -42,8 +42,8 @@ int global_state_store(void)
> void global_state_store_running(void)
> {
> const char *state = RunState_str(RUN_STATE_RUNNING);
> -strncpy((char *)global_state.runstate,
> - state, sizeof(global_state.runstate));
> +strpadcpy((char *)global_state.runstate,
> + sizeof(global_state.runstate), state, '\0');
> }
>
> bool global_state_received(void)
> --
> 2.17.2
>
>
--
Marc-André Lureau
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1803872
Title:
gcc 8.2 reports stringop-truncation when building qemu
Status in QEMU:
New
Bug description:
QEMU 3.0
block/sheepdog.c: In function 'find_vdi_name':
block/sheepdog.c:1239:5: error: 'strncpy' specified bound 256 equals
destination size [-Werror=stringop-truncation]
strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN);
^~
If this is the intended behavior, please suppress the warning. For
example:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wstringop-truncation"
strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN);
#pragma GCC diagnostic pop
This also happens on other sources, for example hw/acpi/core.c, so
another option is to suppress it globally on CFLAGS (-Wno-stringop-
truncation)
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1803872/+subscriptions
[Qemu-devel] [Bug 1784900] Re: QEMU (frontend) crashes upon warm reboot with virtio-gpu device and vga=775 on Linux cmdline
see also "[PATCH] virtio-gpu: fix crashes upon warm reboot with vga
mode" for a potential fix
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1784900
Title:
QEMU (frontend) crashes upon warm reboot with virtio-gpu device and
vga=775 on Linux cmdline
Status in QEMU:
New
Bug description:
With vga=775 on the Linux command line a first boot of the VM running
Linux works fine. After a warm reboot it crashes during Linux boot.
The VM was used remotely via virt-manager and VNC.
Bisecting the code lead to the following patch that introduced the
bug:
commit 1fccd7c5a9a722a9cbf1bc91693f4618034f01ac (HEAD, refs/bisect/bad)
Author: Gerd Hoffmann
Date: Mon Jul 2 18:24:43 2018 +0200
virtio-gpu: disable scanout when backing resource is destroyed
Signed-off-by: Gerd Hoffmann
Reviewed-by: Marc-André Lureau
Message-id: 20180702162443.16796-4-kra...@redhat.com
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 336dc59007..08cd567218 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -430,6 +430,16 @@ static void virtio_gpu_disable_scanout(VirtIOGPU *g, int
scanout_id)
static void virtio_gpu_resource_destroy(VirtIOGPU *g,
struct virtio_gpu_simple_resource
*res)
{
+int i;
+
+if (res->scanout_bitmask) {
+for (i = 0; i < g->conf.max_outputs; i++) {
+if (res->scanout_bitmask & (1 << i)) {
+virtio_gpu_disable_scanout(g, i);
+}
+}
+}
+
pixman_image_unref(res->image);
virtio_gpu_cleanup_mapping(res);
QTAILQ_REMOVE(&g->reslist, res, next);
Reported backtraces can be found here:
https://paste.fedoraproject.org/paste/OUDEfCk1IY7xiy0I0PDlkw
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1784900/+subscriptions
[Bug 1869426] Re: 5.0rc0->4.2 serial migraiton
I thought backward migration wasn't supported.
Isn't it this commit?
commit 4cc017e505df7e5344e4dfe7fc1777c5f11f
Author: Marc-André Lureau
Date: Tue Oct 22 00:32:41 2019 +0200
serial: register vmsd with DeviceClass
Migration from old to new code works, however the other way fails for
devices that use serial_init/serial_mm_init with "base", used as
instance_id previously.
(with qdev_set_legacy_instance_id, the alias_id is only used in
savevm.c:find_se(), and thus can only be used to match against
"legacy" instance id values. On new code, instance_id is generated
incrementally from 0 with calculate_new_instance_id(), based on
"qdev-path/vmsd-name")
Signed-off-by: Marc-André Lureau
Reviewed-by: xiaoqiang zhao
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1869426
Title:
5.0rc0->4.2 serial migraiton
Status in QEMU:
New
Bug description:
Migrating from 5.0rc0->4.2 with pc-q35-4.2 we get an error:
Unknown savevm section or instance 'serial' 1
dumping the migration streams it looks like 5.0 is duplicating the
serial migration data:
"serial (26)": {
"divider": "0x000c",
"rbr": "0x00",
"ier": "0x00",
"iir": "0x01",
"lcr": "0x00",
"mcr": "0x00",
"lsr": "0x60",
"msr": "0xb0",
"scr": "0x00",
"fcr_vmstate": "0x00"
},
"serial (27)": {
"state": {
"divider": "0x000c",
"rbr": "0x00",
"ier": "0x00",
"iir": "0x01",
"lcr": "0x00",
"mcr": "0x00",
"lsr": "0x60",
"msr": "0xb0",
"scr": "0x00",
"fcr_vmstate": "0x00"
}
},
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1869426/+subscriptions
[Bug 1926952] Re: SPICE support broken with 6.0
> launching in terminal separate instance remote-viewer for spice to
passthru usb devices - spice dislay is blank, that was also in 5.x
versions,
That was really a hack. I mean, Spice client shouldn't have a blank
display. You shouldn't have to run both qemu display and remote-viewer.
What you wanted actually is usb redirection with qemu, or you should
simply use spice with gl=on to enable the dmabuf support. In the
meantime, you could patch qemu to keep your hack solution "working".
Btw, we are moving to gitlab for bug tracking (https://gitlab.com/qemu-
project/qemu).
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1926952
Title:
SPICE support broken with 6.0
Status in QEMU:
New
Bug description:
Using latest relase 6.0.0 while using Intel GVT-G DMA-BUF and SPICE
for usb redirection Qemu won't start:
qemu-system-x86_64: The console requires display DMABUF support.
However just patching ui/console.c:
if (flags & GRAPHIC_FLAGS_DMABUF &&
!displaychangelistener_has_dmabuf(dcl)) {
error_setg(errp, "The console requires display DMABUF support.");
return false;
}
to always return true for dmabuf part works just fine:
if (flags & GRAPHIC_FLAGS_DMABUF &&
!displaychangelistener_has_dmabuf(dcl)) {
error_setg(errp, "The console requires display DMABUF support.");
return true;
}
This behavior wasn't in qemu 5.x version.
To reproduce this bug need to use:
/usr/bin/qemu-system-x86_64 \
-machine q35 \
-enable-kvm \
-no-user-config \
-nodefaults \
-no-hpet \
-display gtk,gl=on \
-device
pcie-root-port,port=0x0,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1
\
-device
vfio-pci,id=hostdev2,driver=vfio-pci-nohotplug,romfile=/sys/devices/pci:00/:00:02.0/gvt_firmware,sysfsdev=/sys/bus/mdev/devices/1ae40c36-b180-4af0-8fab-c27de21f597d,x-igd-opregion=on,ramfb=on,display=on,xres=1920,yres=1080,bus=pcie.0,multifunction=on,addr=0x2
\
-spice port=5900,addr=127.0.0.1,disable-ticketing=on
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1926952/+subscriptions
[Qemu-devel] [Bug 1831486] [NEW] qmp monitor deadlock (with spice events for ex)
Public bug reported:
If an event is emitted during monitor_flush_locked() it will deadlock.
Thread 1 (Thread 0x7f14f1854000 (LWP 7245)):
#0 0x7f14fc30592d in __lll_lock_wait () at /lib64/libpthread.so.0
#1 0x7f14fc2fedc9 in pthread_mutex_lock () at /lib64/libpthread.so.0
#2 0x55de60e19327 in qemu_mutex_lock_impl (mutex=0x55de61859e58,
file=0x55de60f1a640 "/home/elmarco/src/qq/monitor.c", line=438) at
/home/elmarco/src/qq/util/qemu-thread-posix.c:66
#3 0x55de6085c5af in monitor_puts (mon=0x55de61859d30, str=0x55de62a61d30
"{\"timestamp\": {\"seconds\": 1559585795, \"microseconds\": 508720},
\"event\": \"SPICE_DISCONNECTED\", \"data\": {\"server\": {\"port\":
\"/tmp/.9IW52Z/spice.sock\", \"family\": \"unix\", \"host\": \"localhost\"},
\"client\": {"...) at /home/elmarco/src/qq/monitor.c:438
#4 0x55de6085c85a in qmp_send_response (mon=0x55de61859d30,
rsp=0x55de61ed19a0) at /home/elmarco/src/qq/monitor.c:493
#5 0x55de6085c8ee in monitor_qapi_event_emit
(event=QAPI_EVENT_SPICE_DISCONNECTED, qdict=0x55de61ed19a0) at
/home/elmarco/src/qq/monitor.c:521
#6 0x55de6085c9ea in monitor_qapi_event_queue_no_reenter
(event=QAPI_EVENT_SPICE_DISCONNECTED, qdict=0x55de61ed19a0) at
/home/elmarco/src/qq/monitor.c:546
#7 0x55de6085cd7a in qapi_event_emit (event=QAPI_EVENT_SPICE_DISCONNECTED,
qdict=0x55de61ed19a0) at /home/elmarco/src/qq/monitor.c:621
#8 0x55de60e04bc3 in qapi_event_send_spice_disconnected
(server=0x55de61ee7b30, client=0x55de620c9090) at qapi/qapi-events-ui.c:101
#9 0x55de60c84381 in channel_event (event=3, info=0x55de6222f4c0) at
/home/elmarco/src/qq/ui/spice-core.c:234
#10 0x7f14fc70ba3b in reds_handle_channel_event (reds=,
event=3, info=0x55de6222f4c0) at reds.c:318
#11 0x7f14fc6f407b in main_dispatcher_self_handle_channel_event
(info=0x55de6222f4c0, event=3, self=0x55de61a5b0b0) at main-dispatcher.c:191
#12 0x7f14fc6f407b in main_dispatcher_channel_event (self=0x55de61a5b0b0,
event=event@entry=3, info=0x55de6222f4c0) at main-dispatcher.c:191
#13 0x7f14fc713cf3 in red_stream_push_channel_event
(s=s@entry=0x55de6222f400, event=event@entry=3) at red-stream.c:416
#14 0x7f14fc713d2b in red_stream_free (s=0x55de6222f400) at red-stream.c:390
#15 0x7f14fc6fa67c in red_channel_client_finalize (object=0x55de62511360)
at red-channel-client.c:347
#16 0x7f14fe4cfcf0 in g_object_unref () at /lib64/libgobject-2.0.so.0
#17 0x7f14fc6fca12 in red_channel_client_push (rcc=0x55de62511360) at
red-channel-client.c:1340
#18 0x7f14fc6fca12 in red_channel_client_push (rcc=0x55de62511360) at
red-channel-client.c:1303
#19 0x7f14fc6cd479 in red_char_device_send_msg_to_client (client=, msg=0x55de62512c00, dev=0x55de61a5b3b0) at char-device.c:307
#20 0x7f14fc6cd479 in red_char_device_send_msg_to_clients
(msg=0x55de62512c00, dev=0x55de61a5b3b0) at char-device.c:307
#21 0x7f14fc6cd479 in red_char_device_read_from_device (dev=0x55de61a5b3b0)
at char-device.c:355
#22 0x55de60a27dba in spice_chr_write (chr=0x55de61924c00,
buf=0x55de6236c070 "{\"return\": {}, \"id\": 2}\r\n", len=25) at
/home/elmarco/src/qq/chardev/spice.c:201
#23 0x55de60d89e29 in qemu_chr_write_buffer (s=0x55de61924c00,
buf=0x55de6236c070 "{\"return\": {}, \"id\": 2}\r\n", len=25,
offset=0x7ffcd5e1a860, write_all=false) at
/home/elmarco/src/qq/chardev/char.c:113
#24 0x55de60d89f96 in qemu_chr_write (s=0x55de61924c00, buf=0x55de6236c070
"{\"return\": {}, \"id\": 2}\r\n", len=25, write_all=false) at
/home/elmarco/src/qq/chardev/char.c:148
#25 0x000055de60d8cf78 in qemu_chr_fe_write (be=0x55de61859d30,
buf=0x55de6236c070 "{\"return\": {}, \"id\": 2}\r\n", len=25) at
/home/elmarco/src/qq/chardev/char-fe.c:42
#26 0x55de6085c40f in monitor_flush_locked (mon=0x55de61859d30) at
/home/elmarco/src/qq/monitor.c:404
#27 0x55de6085c614 in monitor_puts (mon=0x55de61859d30, str=0x55de622f6a40
"{\"return\": {}, \"id\": 2}\n") at /home/elmarco/src/qq/monitor.c:446
#28 0x55de6085c85a in qmp_send_response (mon=0x55de61859d30,
rsp=0x55de61ecf960) at /home/elmarco/src/qq/monitor.c:493
#29 0x55de60865902 in monitor_qmp_respond (mon=0x55de61859d30,
rsp=0x55de61ecf960) at /home/elmarco/src/qq/monitor.c:4128
#30 0x55de60865a19 in monitor_qmp_dispatch (mon=0x55de61859d30,
req=0x55de622ec000) at /home/elmarco/src/qq/monitor.c:4157
#31 0x55de60865ce2 in monitor_qmp_bh_dispatcher (data=0x0) at
/home/elmarco/src/qq/monitor.c:4224
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad
[Qemu-devel] [Bug 1837909] Re: test-char fails if host has no network interfaces
This should be addressed by: https://patchew.org/QEMU/20190713143311.17620-1-marcandre.lur...@redhat.com/ -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1837909 Title: test-char fails if host has no network interfaces Status in QEMU: New Bug description: # ./tests/test-char # random seed: R02S8602535bf831a74bca571d8c416d8161 1..34 # Start of char tests ... ok 12 /char/websocket # Start of stdio tests # End of stdio tests # Start of socket tests # Start of server tests # Start of mainloop tests Unexpected error in inet_parse_connect_saddr() at util/qemu-sockets.c:421: # # address resolution failed for 127.0.0.1:42275: Name or service not known # Aborted (core dumped) # ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever This seems to be related to use of AI_ADDRCONFIG in qemu-sockets.c inet_parse_connect_saddr, dropping it fixes the test. 'man getaddrinfo' makes it sound like AI_ADDRCONFIG requires the host to have a non-loopback ipv4 or ipv6 address available This host setup may seem niche, but it is what the 'mock' RPM build tool has by default. In Fedora we run the test suite during the RPM build, so the failing test causes a bit of pain for certain workflows To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1837909/+subscriptions
[Qemu-devel] [Bug 1815889] Re: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new()
(I reported that issue a few days ago too: https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg06066.html) Perhaps we can teach mesa to not change CPU affinity (some option, or environment variable, or seccomp check). Daniel, when virgl/mesa will be running in a separate process (thanks to vhost-user-gpu), I suppose the rendering process will be free to change the CPU affinity. Does that make a difference if mesa thread is in qemu or a separate process, in this case? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1815889 Title: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new() Status in QEMU: New Status in qemu package in Ubuntu: Triaged Bug description: Unable to launch Default Fedora 29 images in gnome-boxes ProblemType: Crash DistroRelease: Ubuntu 19.04 Package: qemu-system-x86 1:3.1+dfsg-2ubuntu1 ProcVersionSignature: Ubuntu 4.19.0-12.13-generic 4.19.18 Uname: Linux 4.19.0-12-generic x86_64 ApportVersion: 2.20.10-0ubuntu20 Architecture: amd64 Date: Thu Feb 14 11:00:45 2019 ExecutablePath: /usr/bin/qemu-system-x86_64 KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND MachineType: Dell Inc. Precision T3610 ProcEnviron: PATH=(custom, user) ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.19.0-12-generic root=UUID=939b509b-d627-4642-a655-979b44972d17 ro splash quiet vt.handoff=1 Signal: 31 SourcePackage: qemu StacktraceTop: __pthread_setaffinity_new (th=, cpusetsize=128, cpuset=0x7f5771fbf680) at ../sysdeps/unix/sysv/linux/pthread_setaffinity.c:34 () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so start_thread (arg=) at pthread_create.c:486 clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Title: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new() UpgradeStatus: Upgraded to disco on 2018-11-14 (91 days ago) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo video dmi.bios.date: 11/14/2018 dmi.bios.vendor: Dell Inc. dmi.bios.version: A18 dmi.board.name: 09M8Y8 dmi.board.vendor: Dell Inc. dmi.board.version: A01 dmi.chassis.type: 7 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA18:bd11/14/2018:svnDellInc.:pnPrecisionT3610:pvr00:rvnDellInc.:rn09M8Y8:rvrA01:cvnDellInc.:ct7:cvr: dmi.product.name: Precision T3610 dmi.product.sku: 05D2 dmi.product.version: 00 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1815889/+subscriptions
[Qemu-devel] [Bug 1815889] Re: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new()
See also mesa bug: https://bugs.freedesktop.org/show_bug.cgi?id=109695 ** Bug watch added: freedesktop.org Bugzilla #109695 https://bugs.freedesktop.org/show_bug.cgi?id=109695 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1815889 Title: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new() Status in QEMU: New Status in qemu package in Ubuntu: Triaged Bug description: Unable to launch Default Fedora 29 images in gnome-boxes ProblemType: Crash DistroRelease: Ubuntu 19.04 Package: qemu-system-x86 1:3.1+dfsg-2ubuntu1 ProcVersionSignature: Ubuntu 4.19.0-12.13-generic 4.19.18 Uname: Linux 4.19.0-12-generic x86_64 ApportVersion: 2.20.10-0ubuntu20 Architecture: amd64 Date: Thu Feb 14 11:00:45 2019 ExecutablePath: /usr/bin/qemu-system-x86_64 KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND MachineType: Dell Inc. Precision T3610 ProcEnviron: PATH=(custom, user) ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.19.0-12-generic root=UUID=939b509b-d627-4642-a655-979b44972d17 ro splash quiet vt.handoff=1 Signal: 31 SourcePackage: qemu StacktraceTop: __pthread_setaffinity_new (th=, cpusetsize=128, cpuset=0x7f5771fbf680) at ../sysdeps/unix/sysv/linux/pthread_setaffinity.c:34 () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so start_thread (arg=) at pthread_create.c:486 clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Title: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new() UpgradeStatus: Upgraded to disco on 2018-11-14 (91 days ago) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo video dmi.bios.date: 11/14/2018 dmi.bios.vendor: Dell Inc. dmi.bios.version: A18 dmi.board.name: 09M8Y8 dmi.board.vendor: Dell Inc. dmi.board.version: A01 dmi.chassis.type: 7 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA18:bd11/14/2018:svnDellInc.:pnPrecisionT3610:pvr00:rvnDellInc.:rn09M8Y8:rvrA01:cvnDellInc.:ct7:cvr: dmi.product.name: Precision T3610 dmi.product.sku: 05D2 dmi.product.version: 00 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1815889/+subscriptions
[Qemu-devel] [Bug 1813940] Re: kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device
The bug is also reproducible with virtio-9p -fsdev local,id=r,path=/,security_model=none -device virtio-9p-pci,fsdev=r,mount_tag=r I bisected it to the same commit. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1813940 Title: kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device Status in QEMU: New Bug description: Latest QEMU master fails to run with too many MMIO devices specified. After patch 3ac7d43a6fb [1] QEMU just prints an error message and exits. > kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device This is reproducible e.g. with the following setup: qemu-3.1.50-dirty \ -machine pc-i440fx-2.7,accel=kvm \ -cpu host -m 4096 \ -smp 2,sockets=2,cores=1,threads=1 \ -drive file=freebsd_vm_1.qcow2,format=qcow2,if=none,id=bootdr \ -device ide-hd,drive=bootdr,bootindex=0 \ -device virtio-scsi-pci,id=vc0 \ -device virtio-scsi-pci,id=vc1 \ -device virtio-scsi-pci,id=vc2 \ -device virtio-scsi-pci,id=vc3 \ Running with just 3 Virtio-SCSI controllers seems to work fine, adding more than that causes the error above. Note that this is not Virtio- SCSI specific. I've also reproduced this without any Virtio devices whatsoever. strace shows the following ioctl chain over and over: 145787 ioctl(11, KVM_UNREGISTER_COALESCED_MMIO, 0x7f60a4985410) = 0 145787 ioctl(11, KVM_UNREGISTER_COALESCED_MMIO, 0x7f60a4985410) = 0 145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = 0 145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No space left on device) 145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No space left on device) 145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No space left on device) 145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No space left on device) 145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No space left on device) 145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No space left on device) 145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No space left on device) 145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No space left on device) Which suggests there's some kind of MMIO region leak. [1] commit 3ac7d43a6fbb5d4a3d01fc9a055c218030af3727 Author: Paolo Bonzini AuthorDate: Wed Nov 28 17:28:45 2018 +0100 Commit: Paolo Bonzini CommitDate: Fri Jan 11 13:57:24 2019 +0100 memory: update coalesced_range on transaction_commit To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1813940/+subscriptions
[Bug 1898215] Re: [git][archlinux]Build process is busted in spice-display.c
This is a bug in the spice-server meson build system:
https://gitlab.freedesktop.org/spice/spice/-/commit/37fd91a51f52cdc1b55d3ce41e6ce6db348b986c
Most likely they will end up bumping the version to 0.15, so we may want
to update the condition in qemu.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1898215
Title:
[git][archlinux]Build process is busted in spice-display.c
Status in QEMU:
New
Bug description:
Linux distribution: Archlinux. Crash log added is based on a build
from scratch.
Gcc version: 10.2.0
Configure options used:
configure \
--prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--libexecdir=/usr/lib/qemu \
--extra-ldflags="$LDFLAGS" \
--smbd=/usr/bin/smbd \
--enable-modules \
--enable-sdl \
--disable-werror \
--enable-slirp=system \
--enable-xfsctl \
--audio-drv-list="pa alsa sdl"
Crash log:
../ui/spice-display.c: In function 'interface_client_monitors_config':
../ui/spice-display.c:682:25: error:
'VD_AGENT_CONFIG_MONITORS_FLAG_PHYSICAL_SIZE' undeclared (first use in this
function); did you mean 'VD_AGENT_CONFIG_MONITORS_FLAG_USE_POS'?
682 | if (mc->flags & VD_AGENT_CONFIG_MONITORS_FLAG_PHYSICAL_SIZE) {
| ^~~
| VD_AGENT_CONFIG_MONITORS_FLAG_USE_POS
../ui/spice-display.c:682:25: note: each undeclared identifier is reported
only once for each function it appears in
../ui/spice-display.c:683:13: error: unknown type name 'VDAgentMonitorMM'
683 | VDAgentMonitorMM *mm = (void
*)&mc->monitors[mc->num_of_monitors];
| ^~~~
../ui/spice-display.c:684:37: error: request for member 'width' in something
not a structure or union
684 | info.width_mm = mm[head].width;
| ^
../ui/spice-display.c:685:38: error: request for member 'height' in something
not a structure or union
685 | info.height_mm = mm[head].height;
| ^
make: *** [Makefile.ninja:2031: libcommon.fa.p/ui_spice-display.c.o] Error 1
make: *** Waiting for unfinished jobs
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1898215/+subscriptions
[Bug 1903470] Re: qemu 5.1.0: Add UNIX socket support for netdev socket
With the fd= argument/property, you can setup a private socketpair connection already. Is this enough? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1903470 Title: qemu 5.1.0: Add UNIX socket support for netdev socket Status in QEMU: New Bug description: Note: this is a feature request. qemu has a way to connect instances using a socket: -netdev socket,id=str[,fd=h][,listen=[host]:port][,connect=host:port] This can also be used to connect a qemu instance to something else using a socket connection, however there is no authentication or security to the connection, so rather than using a port which can be accessed by any user on the machine, having the ability to use or connect to UNIX sockets would be helpful, and adding this option should be fairly trivial. UNIX sockets can be found in various parts of qemu (monitor, etc) so I believe having this on network would make sense. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1903470/+subscriptions
