[Bug 1915531] Re: qemu-user child process hangs when forking due to glib allocation

As a quick win, we ought to call setenv("G_SLICE", "always-malloc", 1) during startup to avoid the specific scenario you hit. A more general solution is likely to be non-trivial. glib is such a fundamental part of QEMU that is is hard to avoid its usage. The async-signal safety issues only

[Bug 304636] Re: -hda FAT:. limited to 504MBytes

If you need OS portability then the "usb-mtp" device is also an option for adhoc file sharing. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/304636 Title: -hda FAT:. limited to 504MBytes Status

[Bug 1911188] Re: qemu-system-x86_64 prints obscure error message and exits when encountering an empty argument

If QEMU receives an argument that isn't an option flag, then it considers it to be the path to a disk. The block code treats the empty string as indicating that no backing file should be opened for the device. This only makes sense for devices that support removable media (ie CDROM, floppy), hence

[Bug 1905979] Re: Check if F_OFD_SETLK is supported may give wrong result

Look in the same directory as that .deb link above - the the files ending in orig.tar.gz (upstream source) and files ending in debian.tar.xz (downstream modifications) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Bug 1905979] Re: Check if F_OFD_SETLK is supported may give wrong result

** 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/1905979 Title: Check if F_OFD_SETLK is supported may give wrong result Status in QEMU:

[Bug 1905979] Re: Check if F_OFD_SETLK is supported may give wrong result

In this thread, it is pointed out that support for OFD is provided by the generic VFS layer in the kernel, so there should never be a situation where one filesystem supports OFD and another does not support OFD: https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg05264.html Can you say

[Bug 1906180] Re: Keyboard keys get stuck

Can you confirm whether you are executing QEMU on your local desktop/laptop machine, or remotely over SSH with X11-forwarding, or over a remote VNC server, etc ? In the remote cases stuck keys is somewhat of a known problem especially if latency is bad -- You received this bug notification

[Bug 1903712] Re: when ../configure, cannot find Ninjia

** 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/1903712 Title: when ../configure, cannot find Ninjia Status in QEMU: Incomplete Bug

[Bug 1690322] Re: errors which can't backing storage for guest RAM with -mem-path

The memory region mapped by QEMU for -mem-path is configured such that changes are private to the QEMU process. If you need an external process to be able to view memory changes, you need to use the modern "memory-backend-file" class with -object arg, and specify share=on to make the data

[Bug 1903712] Re: when ../configure, cannot find Ninjia

Can you confirm whether you have installed the "ninja-build" package ? It is a new build requirement for QEMU in 5.2.0 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1903712 Title: when

[Bug 1902470] Re: migration with TLS-MultiFD is stuck when the dst-libvirtd service restarts

This looks to me like a significant implementation flaw in the QEMU code. Both src and dst QEMU appear to be running code from the main event loop, and they appear to be doing blocking I/O operations. This is very bad as we should never have anything running in the main event loop thread that is

[Bug 1900352] Re: no sound in spice when VNC enabled

If VNC is enabled, then libvirt sets QEMU_AUDIO_DRV=none unless /etc/libvirt/qemu.conf is set to allow output to host audio. Clearly this doesn't do the right thing when SPICE is present at the same time as VNC, but that's libvirt's fault rather than QEMU. -- You received this bug notification

[Bug 1502884] Re: Super important feature req: QEMU VNC server: Introduce a keyboard "norepeat" option!

The VNC server doesn't get involved in key repeat functionality, it just passes keys from the client onto the guest OS. The client can indicate that it is doing key repeat by sending a series of "key down" events, and only 1 "key up" event to indicate end of auto-repeat. The guest OS can itself

[Bug 1896096] Re: Git version: Build process is broken in block_curl.c.o

FWIW, I reproduced the original failure using your LDFLAGS, and tested that removing '-pie' made it work -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1896096 Title: Git version: Build process is

[Bug 1896096] Re: Git version: Build process is broken in block_curl.c.o

Before the meson port, the "-pie" arg was on the CLI *before* the "-shared" arg so the "-shared" wins and results in a shared library. After the meson port, "-shared" appears first, and so "-pie" wins and tries to create an executable. IOW, this passing of -pie was always wrong, and it was only

[Bug 1896096] Re: Git version: Build process is broken in block_curl.c.o

FYI, QEMU automatically enables PIC/PIE as needed, so there's no need to set it via these flags. In fact everything in your $CFLAGS is already set by QEMU out of the box too. For LDFLAGS you can cull the -g and -pie -- You received this bug notification because you are a member of qemu-

[Bug 1896096] Re: Git version: Build process is broken in block_curl.c.o

The problem is caused by the extra flags you're forcing on the compiler: Using 'CFLAGS' from environment with value: '-O2 -g -fPIE -DPIE -std=gnu99 -Wall' Using 'LDFLAGS' from environment with value: '-g -pie -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' Using 'CPPFLAGS' from environment

[Bug 1896096] Re: Git version: Build process is broken in block_curl.c.o

Can you do the build using "make V=1" so that we actually see the compiler command lines used in the log file. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1896096 Title: Git version: Build

[Bug 1896096] Re: Git version: Build process is broken in block_curl.c.o

Added Paolo for his Meson expertize in case he can spot the flaw -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1896096 Title: Git version: Build process is broken in block_curl.c.o Status in

[Bug 1896096] Re: Git version: Build process is broken in block_curl.c.o

Nothing looks especially unusual there, but clear it is failing to link the block-curl.so as a library and is instead linking it as an executable and thus failing to find "main". I can't explain why that would be the case. -- You received this bug notification because you are a member of qemu-

[Bug 1896096] Re: Git version: Build process is broken in block_curl.c.o

Can you attach the full build log, including all the "configure" output, and ideally pass "V=1" as an arg to 'make' -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1896096 Title: Git version: Build

[Bug 1896096] Re: Git version: Build process is broken in block_curl.c.o

Please give more info on your host OS build environment, and most importantly confirm that you have tried doing a build from a *completely* clean git checkout. Recent build system changes introduced risk of problems if you have not done a full clean. "git clean -f -x -d" will delete every file in

[Bug 1893691] Re: Chardev logfile is not written (regression between 5.0 and 5.1)

https://lists.gnu.org/archive/html/qemu-devel/2020-09/msg04809.html ** Changed in: qemu Status: New => Confirmed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1893691 Title: Chardev

[Bug 1893691] Re: Chardev logfile is not written (regression between 5.0 and 5.1)

This regression is specific to the "socket" chardev and was caused by this commit: commit 271094474b65de1ad7aaf729938de3d9b9d0d36f (refs/bisect/bad) Author: Dima Stepanov Date: Thu May 28 12:11:18 2020 +0300 char-socket: return -1 in case of disconnect during tcp_chr_write During

[Bug 1826200] Re: RFE: populate "OEM Strings" (type 11) SMBIOS table strings from regular files

Surprise... https://lists.gnu.org/archive/html/qemu-devel/2020-09/msg03023.html Discovering the firmware limits was tedious. SeaBIOS limits SMBIOS to 64KB total size due to support for SMBIOS 2.1 spec only, while EDK2 fails a little over 128 KB total size despite supporting SMBIOS 3.0 which

[Bug 1894804] Re: Second DEVICE_DELETED event missing during virtio-blk disk device detach

Note that there are many VMs running, so it is important to isolate logs for just one of them, by matching on mon=0x. For example considering this $ grep 0x7f021c0b9c70 libvirtd.log | grep -E 'QEMU_MONITOR_(RECV_REPLY|RECV_EVENT|SEND_MSG)' We can see the "device_del" request:

[Bug 1893040] Re: External modules retreval using Go1.15 on s390x appears to have checksum and ECDSA verification issues

** Changed in: qemu Status: Incomplete => Opinion ** Changed in: qemu Status: Opinion => Invalid ** Changed in: qemu Status: Invalid => New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Bug 1893040] Re: External modules retreval using Go1.15 on s390x appears to have checksum and ECDSA verification issues

Can you provide a *simple* way to demonstrate the problem. ie some simple Go demo program, that doens't involve building kubernetes. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1893040 Title:

[Bug 1893040] Re: External modules retreval using Go1.15 on s390x appears to have checksum and ECDSA verification issues

> We are observing issue while building go-runner image and we suspect it is > due to QEMU version > being used. As referred in below issue: > https://github.com/golang/go/issues/40949 This issue says the problem was due to https://bugs.launchpad.net/qemu/+bug/1847232/ which was fixed in QEMU

[Bug 1818075] Re: qemu x86 TCG doesn't support AVX insns

QEMU, like most open source projects, relies on contributors who have motivation, skills and available time to work on implementing particular features. They naturally tend to focus on features that result in the greatest benefit to their own use cases. Thus simply declaring that an open source

[Bug 1659267] Re: It's not possible to start a VM with a network cable unplugged

Note that you can start QEMU with the "-S" flag which means CPUS are paused. This gives you ability to run the "set_link" monitor command above, and then run "cont" to actually start the VM. Less convenient that a CLI flag, but functionally it is eqivalent. -- You received this bug notification

[Bug 1879672] Re: QEMU installer with WHPX support

Has anyone raised an RFE with the mingw64 project to provide these headers / APIs ? That's what provides the interfaces we usually rely on for Windows builds, and they're likely familiar with what they can & can't do from a legal POV. I don't see this as something QEMU needs to solve itself. --

[Bug 1878348] Re: --static build fails in v5.0 (since 5010cec2bc87dafab39b3913c8ca91f88df9c540)

Semi-officially, QEMU only aims to support static linking with usermode emulators, not system mode emulators. I'm not sure we make that clear anywhere in the docs, or configure script. We should probably print a warning from configure if using --static in combination with system emulators, that

[Bug 1875819] Re: [Feature request] prebuilt testing docker images

GitLab has ability to host container images per project and also can build them during CI runs. So I'd suggest that we create GitLab CI jobs that build & publish each of the images under tests/docker on the master branch. -- You received this bug notification because you are a member of qemu-

[Bug 1875139] Re: Domain fails to start when 'readonly' device not writable

> This issue is introduced in QEMU 4.2.0 (4.1.0 is working fine) That's not neccessarily the case - with QEMU 4.2.0, libvirt switched over to using the new -blockdev command line syntax. When you were testing with 4.1.0, it would have been using the legacy -drive syntax. So the change in

[Bug 1875139] Re: Domain fails to start when 'readonly' device not writable

Can you provide the full guest XML for this - "/etc/libvirt/qemu/$GUESTNAME.xml", and also the full QEMU command line - "/var/log/libvirt/qemu/$GUESTNAME.xml". We need to see whether the disk is considered read-only from libvirt's POV. -- You received this bug notification because you are a

[Bug 1868221] Re: /usr/share/applications/qemu.desktop should have an "Exec=" key.

Note that QEMU sets the NoDisplay=true property to tell desktops not to display this entry. I don't think KDE should be warning about missing Exec entry in this case. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Bug 1868221] Re: /usr/share/applications/qemu.desktop should have an "Exec=" key.

Adding an exec field would not be right, because QEMU can't simply be launched from the desktop without any arguments. There needs to be a long string of arguments given that are different for every QEMU that is launched. The only viable way to actually launch QEMU is interactively from the

[Bug 1867519] Re: qemu 4.2 segfaults on VF detach

That commit you mention is confirmed to solve a bug reported against Fedora with almost the same stack trace you see here. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1867519 Title: qemu 4.2

[Bug 1863601] Re: unable to type "|" character in french keyboard.

Actually you explicitly do *NOT* want to select any keymap in virt- manager in general. Picking a keymap disables the VNC protocol extension for raw scancodes. This means that QEMU has to do keymap <-> scancode conversion. In such a setup the host OS desktop keymap, the QEMU keymap and the guest

[Bug 1863601] Re: unable to type "|" character in french keyboard.

Can you provide the QEMU command line (/var/log/libvirt/qemu/$GUEST.log) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1863601 Title: unable to type "|" character in french keyboard. Status in

[Bug 1863601] Re: unable to type "|" character in french keyboard.

Can you provide more information here. What command line have you launched QEMU with ? How are you interacting with QEMU (serial console, GTK UI, VNC, SPICE ?) If VNC/SPICE, what client app are you using ? -- You received this bug notification because you are a member of qemu- devel-ml, which

[Bug 1849644] Re: QEMU VNC websocket proxy requires non-standard 'binary' subprotocol

** Changed in: qemu Status: New => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1849644 Title: QEMU VNC websocket proxy requires non-standard 'binary' subprotocol Status in

[Bug 823733] Re: Solaris can't be powered off with ACPI shutdown/poweroff

** Summary changed: - Soloaris can't be poweroff + Solaris can't be powered off with ACPI shutdown/poweroff -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/823733 Title: Solaris can't be powered

[Bug 1860575] Re: qemu64 CPU model is incorrect

Your analysis of the problem with family makes sense & we do have mechanism to fix this in QEMU while keeping back compat for existing deployments. I'm curious as to the actual errors LLVM reports ? FWIW, even though qemu64 is the default CPU, practically everyone would be better off choosing

[Bug 1849644] Re: QEMU VNC websocket proxy requires non-standard 'binary' subprotocol

It isn't mandatory to use a standardized subprotocol, all that's required is that the client & server agree https://developer.mozilla.org/en- US/docs/Web/HTTP/Protocol_upgrade_mechanism "The subprotocols may be selected from the IANA WebSocket Subprotocol Name Registry or may be a custom

[Qemu-devel] [Bug 1838658] Re: qemu 4.0.0 broken by glib update

Doh, sorry for my comment earlier where I mistakenly used sparc instead of sparc64. I've now tested QEMU git master with that sparc64 ISO and qemu-system- sparc64. I still can't reproduce it though - it boots past the disk probing, and into the installer, where it asks for the terminal type.

[Qemu-devel] [Bug 1838658] Re: qemu 4.0.0 broken by glib update

The test image that the netbsd bug points to no longer exists. If I pick the image currently available: http://nycdn.netbsd.org/pub/NetBSD- daily/HEAD/latest/images/NetBSD-9.99.2-sparc.iso And launch it in a QEMU built from today's GIT master, on Fedora 30 with glib2 2.60.5, NetBSD

[Qemu-devel] [Bug 1838658] Re: qemu 4.0.0 broken by glib update

Fedora 30 has been shipping glib2 2.60.0 through to 2.60.5 and QEMU in general has been working normally AFAICT. >From the netbsd bug report it looks like the reproducer was demoed using the sparc emulator - is that the only QEMU arch that is affected ? -- You received this bug notification

[Qemu-devel] [Bug 1838312] Re: Qemu virt-manager Segmentation fault

** Also affects: virt-manager (Ubuntu) Importance: Undecided Status: New ** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1838312 Title:

[Qemu-devel] [Bug 676934] Re: Ability to use -net socket with unix sockets

This is just about connecting the NIC backends for 2 QEMUs together using a UNIX socket, instead of the current TCP/UDP socket. It should be fairly trivial to support i would expect. Though ideally we'd port the netdev socket backend to use QIOChannel too -- You received this bug notification

[Qemu-devel] [Bug 1828608] Re: Chardev websocket might not support pasting more than a few chars

If the problem only happens with a websockets channel enabled, it possibly a bug in the QIOChannelWebsock impl rather than the chardev -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1828608 Title:

[Qemu-devel] [Bug 1828272] Re: 4.0 breaks keyboard autorepeat in guests with xserver

Adding Gerd to the CC, since this is possibly caused by recent work to keyboard state tracking code. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1828272 Title: 4.0 breaks keyboard autorepeat in

[Qemu-devel] [Bug 1828207] Re: Request to add something like "Auth failed from IP" log report for built-in VNC server

The challenge is that this is the only auth scheme defined by the VNC protocol, aside from no-auth. If we removed it, we'd no longer be compatible with the standard VNC protocol. We'd be making use of the TLS/SASL extensions mandatory if users want auth. This could ultimately push people to

[Qemu-devel] [Bug 1828207] Re: Request to add something like "Auth failed from IP" log report for built-in VNC server

Note that any use of the built-in VNC-auth scheme is always considered a security flaw. It should essentially never be used, especially not on any public internet facing service, even if fail2ban were able to be used. A secure VNC server should use the VeNCrypt extension which enables TLS, with

[Qemu-devel] [Bug 1826200] Re: RFE: populate "OEM Strings" (type 11) SMBIOS table strings from regular files

** Changed in: qemu Status: New => Confirmed ** Changed in: qemu Assignee: (unassigned) => Daniel Berrange (berrange) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1826200 Title:

[Qemu-devel] [Bug 1826175] Re: Compilation on MSYS2/MinGW-w64 fails with error: "No rule to make target capstone.lib"

Re-opened, since although the fix needs to be done in capstone, QEMU also needs a commit to actually update the submodule hash to pull in the fix. ** Changed in: qemu Status: Invalid => New -- You received this bug notification because you are a member of qemu- devel-ml, which is

[Qemu-devel] [Bug 1826175] Re: Compilation on MSYS2/MinGW-w64 fails with error: "No rule to make target capstone.lib"

NB that patch will break Linux based Mingw builds, as they don't include "mys2" in their output from gcc, so it would need to match both. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1826175 Title:

[Qemu-devel] [Bug 1824528] Re: qemu fails to compile on gcc 9 `error: taking address of packed member of ‘struct ’ may result in an unaligned pointer value [-Werror=address-of-packed-member

Fixed in https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg02524.html ** Changed in: qemu Status: New => In Progress -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1824528 Title:

[Qemu-devel] [Bug 1824528] Re: qemu fails to compile on gcc 9 `error: taking address of packed member of ‘struct ’ may result in an unaligned pointer value [-Werror=address-of-packed-member

This struct represents the MTP protocol wire format so *must* be marked packed. There unfortunately quite a few flaws in this MTP code area, so fixing the gcc warning is not straightforward. https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg07763.html -- You received this bug

[Qemu-devel] [Bug 1823152] Re: QEMU not able to boot ubuntu 18.04 as a guest

Switched bug to the ubuntu qemu package, since qemu-system-x86_64-spice is not an upstream provided binary ** Also affects: qemu (Ubuntu) Importance: Undecided Status: New ** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member

[Qemu-devel] [Bug 1815889] Re: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new()

FYI the QEMU change merged in the following pull request changed to return an EPERM errno for the thread affinity syscalls: commit 12f067cc14b90aef60b2b7d03e1df74cc50a0459 Merge: 84bdc58c06 035121d23a Author: Peter Maydell Date: Thu Mar 28 12:04:52 2019 + Merge remote-tracking branch

[Qemu-devel] [Bug 1815889] Re: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new()

I did wonder if we could set the action for some syscalls to be "errno" instead of "kill process", but I worry that could then result in silent mis-behaviour as processes fail to check return value as they blindly assume the call cannot fail. We should probably talk with mesa developers about

[Qemu-devel] [Bug 1815889] Re: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new()

As & when libvirt & QEMU supports the external vhost processes for this I expect it will still restrict the CPU affinity and apply seccomp filters that likely to be as strict as they are today at minimum. -- You received this bug notification because you are a member of qemu- devel-ml, which is

[Qemu-devel] [Bug 1815889] Re: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new()

IMHO that mesa change is not valid. It is settings its affinity to run on all threads which is definitely *NOT* something we want to be allowed. Management applications want to control which CPUs QEMU runs on, and as such Mesa should honour the CPU placement that the QEMU process has. This is a

[Qemu-devel] [Bug 1816819] Re: Chardev websocket stops listening after first connection disconnects

Patch proposed https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg05556.html -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1816819 Title: Chardev websocket stops listening after first

[Qemu-devel] [Bug 1816052] [NEW] qemu system emulator fails to start if no sound card is present on host

Public bug reported: A plain build from git master at 81dbcfa9e1d8bab3f7c4cc923c0b40cd666f374f on Fedora 29 x86_64 host, with no options passed to configure. Trying to launch QEMU on a host with no audio card present: # ls /dev/snd/ seq timer It will fail to initialize alsa and abort

[Qemu-devel] [Bug 1795100] Re: VNC unix-domain socket unlink()ed prematurely

Fix merged to git master https://git.qemu.org/?p=qemu.git;a=commit;h=feff02089113839d233e40a9bd7134241de12d1d ** Changed in: qemu Status: New => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1811711] Re: qemu-img can not convert virtualbox virtual disk formats qcow

This bug was related to an IRC discussion on Jan 14th but this bug description is not showing the problem that was raised on IRC. The IRC discussion showed a source image with a 9GB Windows 10 installation, turning into an image with only 8 MB of data present. The images in this bug description

[Qemu-devel] [Bug 1795100] Re: VNC unix-domain socket unlink()ed prematurely

Patch proposed at https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg02774.html -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1795100 Title: VNC unix-domain socket unlink()ed prematurely

[Qemu-devel] [Bug 1795100] Re: VNC unix-domain socket unlink()ed prematurely

It only affects VNC, not chardevs because the chardevs fail to call qio_channel_close() and just rely on finalize() cleaning up the open socket. To fix this we just need to made the code conditional on it being a listener socket if (qio_channel_has_feature(ioc, QIO_CHANNEL_FEATURE_LISTEN)) {

[Qemu-devel] [Bug 1809252] Re: Password authentication in FIPS-compliant mode

The VNC password authentication scheme is not extensible. It is unfixably broken by design. QEMU provides the SASL authentication scheme for VNC which allows for strong authentication, when combined with the VeNCrypt authentication scheme that uses TLS. These extensions are supported by the

[Qemu-devel] [Bug 1738283] Re: 'Less than' (<), 'more than' (>), and 'pipe' (|) can't be typed via VNC

Discussing the problem & likely solution here: https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04631.html -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1738283 Title: 'Less than' (<),

[Qemu-devel] [Bug 1392468] Re: qemu uses a bitmap icon

This series gives the QEMU SDL2 & GTK frontends high quality icons http://lists.nongnu.org/archive/html/qemu-devel/2018-12/msg04475.html -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1392468 Title:

[Qemu-devel] [Bug 1803872] Re: [PATCH v2 0/3] Fix strncpy() warnings for GCC8 new -Wstringop-truncation

On Tue, Dec 18, 2018 at 09:31:00AM -0500, Michael S. Tsirkin wrote: > On Tue, Dec 18, 2018 at 12:03:30PM +0100, Philippe Mathieu-Daudé wrote: > > GCC 8 new warning prevents builds to success since quite some time. > > First report on the mailing list is in July 2018: > >

[Qemu-devel] [Bug 1801933] Re: default memory parameter too small on x86_64 today

IMHO, if achieving ease of use comparable to VirtualBox is your benchmark target, then launching QEMU directly is really the wrong way to approach things. QEMU is a very low level piece of infrastructure not a complete end user desktop solution. For that it is better to look at using an

[Qemu-devel] [Bug 1790617] Re: Version of disk image format not exhibited using the 'qemu-img info' command

There's no concept of versions for "raw" images as there's no metadata at all - its just raw disk content. For the qcow2 format, the version 2 vs version 3 distinction is not something that is intended to be exposed externally. A version 3 format file is still handled by the qcow2 format driver,

[Qemu-devel] [Bug 1790268] Re: the vhd generated by qemu-img not align with MB again.

It is -o subformat=fixed which breaks the file format detection -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1790268 Title: the vhd generated by qemu-img not align with MB again. Status in

[Qemu-devel] [Bug 1788665] Re: Low 2D graphics performance with Windows 10 (1803) VGA passthrough VM using "Spectre" protection

There is always a performance differential between bare metal & VMs. The actual amount varies depending on alot of different factors and meltdown/spectre have had an effect here - the actual perf hit depends on the CPU models & virtual hardware and more besides - ranging anywhere from 0% to 40%

[Qemu-devel] [Bug 1788665] Re: Low 2D graphics performance with Windows 10 (1803) VGA passthrough VM using "Spectre" protection

> Whew, after some hurdles I managed to install a Linux Mint 19 guest (Ubuntu > 18.04). After all updates, here the output: > > $ dmesg | grep microcode > [ 0.036780] core: PEBS disabled due to CPU errata, please upgrade microcode > > So the microcode in the guest is not loaded! But see below:

[Qemu-devel] [Bug 1788665] Re: Low 2D graphics performance with Windows 10 (1803) VGA passthrough VM using "Spectre" protection

I'm not convinced we can trust the output from cygwin wrt CPU flags. A better test would be to install a modern Linux guest which has the mitigations, and see if that reports the flags. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to

[Qemu-devel] [Bug 1788665] Re: Low 2D graphics performance with Windows 10 (1803) VGA passthrough VM using "Spectre" protection

You're mis-understanding how microcode works a little. Microcode is loaded into physical CPUs in the host. This affects everything that runs on these CPUs thereafter. A KVM guest is merely a process running on the host CPUs, so it is affected by the updated microcode. There is no notion of the

[Qemu-devel] [Bug 1788665] Re: Low 2D graphics performance with Windows 10 (1803) VGA passthrough VM using "Spectre" protection

QEMU is already capable of exposing the new CPU features to guests, so possibly a mis-configuration. Please provide the full QEMU command line args you are using for this guest too. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1787012] Re: Solaris build error: Bad string

** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1787012 Title: Solaris build error: Bad string Status in QEMU: Invalid Bug description: While

[Qemu-devel] [Bug 1787012] Re: Solaris build error: Bad string

It sounds more like a bug / limited featureset in the Solaris 'tr' binary. What is your $PATH ? Make sure /usr/xpg4/bin directory appears *before* /usr/bin in $PATH to get a more functional version of 'tr', though I'm not sure if that'll fix it or not. -- You received this bug notification

[Qemu-devel] [Bug 1785698] Re: Solaris build error: unknown type name ‘gcry_error_t’

> I notice in the Makefile in dtc/ that it's calling python. My default > python is 2.6.9. I found some discussion about qemu moving to python > 3. Could this be the problem? We require either Python 2.7.x, or Python 3.x versions. Support for 2.6.x was dropped I'm afraid. -- You received this

[Qemu-devel] [Bug 1785698] Re: Solaris build error: unknown type name ‘gcry_error_t’

Adding #include is definitely wrong. You are instead missing the right -I include path. The libgcrypt-config command should be in $PATH, and should print "-I/opt/csw/include" args when running "libgcrypt-config --cflags". If that doesn't happen, then the gcrypt installation is broken. -- You

[Qemu-devel] [Bug 1784900] Re: QEMU (frontend) crashes upon warm reboot with virtio-gpu device and vga=775 on Linux cmdline

** Summary changed: - QEMU (frontend) crashes upon warm reboot with vga=775 on Linux cmdline + QEMU (frontend) crashes upon warm reboot with virtio-gpu device and vga=775 on Linux cmdline -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to

[Qemu-devel] [Bug 1778966] Re: Windows 1803 and later crashes on KVM

This sounds like the same problem we're investigating in Fedora/RHEL land affecting guests with EPYC CPU, or host-passthrough from an EPYC family 17h host. Workaround should be to use "-cpu Opteron_G5" for now https://bugzilla.redhat.com/show_bug.cgi?id=1592276

[Qemu-devel] [Bug 1775366] Re: [Feature request] qemu-ga - Allow unexpected parameter

BTW, if you have any friendly contact with the your hosting provider, please encourage them to contribute any enhancements they have back to QEMU. It is highly desirable to *NOT* have hosting providers needing a fork of qemu-ga, as that ruins ability to run standard disk images, as you've found.

[Qemu-devel] [Bug 1775555] Re: guest migration 100% cpu freeze bug

I don't have any suggestions wrt the actual bug cause, but just want to suggest adding the XML config and corresponding CLI args used on both the source and dest hosts (see /var/log/libvirt/qemu/$GUEST.log) to this bug, for one of the VMs that sees the 100% CPU hang. -- You received this bug

[Qemu-devel] [Bug 1769053] Re: Cannot start a guest with more than 1TB of RAM

Hmm, if we know that QEMU guests will crash & burn when > 1 TB mem, when host-phys-bits/phys-bits are unset, then perhaps libvirt should do the right thing by default here. eg we can't use host-phys-bits=true due to migration compat issues, but if we see > 1TB mem, libvirt could reasonably set

[Qemu-devel] [Bug 1654137] Re: Ctrl-A b not working in 2.8.0

@elmarco could you take a look at this possible regression since bisect claims it was due to the mux refactor -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1654137 Title: Ctrl-A b not working in

[Qemu-devel] [Bug 1756519] Re: qemu linux-user crash in QOM path canonicalization during do_fork() call to cpu_create

** Summary changed: - qemu linux-user glib hash table crash in qom/object.c + qemu linux-user crash in QOM path canonicalization during do_fork() call to cpu_create -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1747056] Re: FreeDOS / MS-Dos / Windows 3.11 cannot perform reboot with 'isapc' machine

We need to pull in a SeaBIOS update with this fix applied to resolve this commit 42812e062a77b27b0544c8e0d46d206afc3b2fae Author: Kevin O'Connor Date: Thu Feb 22 20:29:27 2018 -0500 shadow: Don't invoke a shutdown on reboot unless in a reboot loop Old versions

[Qemu-devel] [Bug 1747056] Re: FreeDOS / MS-Dos / Windows 3.11 cannot perform reboot with 'isapc' machine

I bisected seabios and found this seabios change to be the cause of the problem commit b837e68d5a6c1a5945513f1995875445a1594c8a (refs/bisect/bad) Author: Kevin O'Connor Date: Mon Nov 9 15:00:19 2015 -0500 resume: Make KVM soft reboot loop detection more flexible

[Qemu-devel] [Bug 1747056] [NEW] FreeDOS / MS-Dos / Windows 3.11 cannot perform reboot with 'isapc' machine

Public bug reported: I was installing MS-Dos 6.22 + Windows 3.11 in preparation for running Microsoft Bob, and noticed that when they try to perform a reboot, they just get stuck. The console cursor stays flashing on/off, but the DOS prompt no longer responds to input. It is fairly easy to

[Qemu-devel] [Bug 1703795] Re: Unable to release mouse in SDL2 mode

Can you file a separate bug for the SDL1 backspace problem - it was not intended to cause problems like that. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1703795 Title: Unable to release mouse

[Qemu-devel] [Bug 1089496] Re: qemu doesn't set vnc port correctly

The problem with this is that the behaviour is inherently ambiguous. We have no way to distinguish whether a user specifying ":5804" wants port 11704 or port 5804, so it is not in fact easy to fix. If we were writing this again from scratch I would avoid the offset concept entirely and always

[Qemu-devel] [Bug 1708462] Re: Support Python 3 to build

Two patches series posted in Aug last year: https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg03642.html https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg06528.html An updated series covering both of those, and also turning on tests

  1   2   >