[Bug 1834051] Re: IRQ2 ignored under KVM when using IOAPIC
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1834051 Title: IRQ2 ignored under KVM when using IOAPIC Status in QEMU: Incomplete Bug description: When using KVM, and an OS that supports the IOAPIC, interrupts mapped on IRQ2 (for instance, routing an HPET timer on interrupt 2) will cause the interrupts to never be delivered. This is because QEmu, when setting up the KVM interrupt routes, will not set one up for IRQ2[0]. When running without KVM, IRQ2 is identity-mapped to GSI2. My understanding is that IRQs should be identity mapped to their equivalent GSI unless a redirection entry is present in the MADT. This is supported by ACPI 6.2 spec[1], 5.2.12.5 Interrupt Source Override Structure, which claims: "It is assumed that the ISA interrupts will be identity-mapped into the first I/O APIC sources.". I stumbled across this while working on my own custom OS, got very confused why the HPET wasn't triggering any interruption - and even more confused why the behavior only happened in KVM and not in non- KVM. EDIT: Interestingly, the HPET only supports IRQ2 when using the default PIIX chipset, which, combined with this bug, makes it completely unusable. [0]: https://github.com/qemu/qemu/blob/37560c259d7a0d6aceb96e9d6903ee002f4e5e0c/hw/i386/kvm/ioapic.c#L40 [1]: https://uefi.org/sites/default/files/resources/ACPI_6_2.pdf To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1834051/+subscriptions
[Bug 1835466] Re: qemu 4.0.0 abort()s in audio_get_pdo_in (poisoned drv->driver?)
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1835466 Title: qemu 4.0.0 abort()s in audio_get_pdo_in (poisoned drv->driver?) Status in QEMU: Incomplete Bug description: After upgrading qemu from 3.0.0 to 4.0.0 (compiled from release tarball), I'm seeing a (reproducible) crash related to audio subsystem. I recompiled qemu with debugging options and got it to crash under gdb: Thread 6 "qemu-system-x86" received signal SIGABRT, Aborted. 0x752e420b in raise () from /lib64/libc.so.6 (gdb) bt #0 0x752e420b in raise () at /lib64/libc.so.6 #1 0x752c6524 in abort () at /lib64/libc.so.6 #2 0x0041ec33 in audio_get_pdo_in (dev=) at audio/audio_template.h:328 #3 0x005d0123 in AUD_open_in (card=0x7ffdde98dbc8, sw=0x717444e0, name=0x999d80 "adc", callback_opaque=callback_opaque@entry=0x7ffdde98fd58, callback_fn=0x610940 , as=as@entry=0x7ffdde98fd84) at audio/audio_template.h:434 #4 0x0060fe2e in hda_audio_setup (st=0x7ffdde98fd58) at hw/audio/hda-codec.c:490 #5 0x0061051b in hda_audio_command (hda=0x7ffdde98db40, nid=4, data=) at hw/audio/hda-codec.c:590 #6 0x0060ea20 in intel_hda_send_command (d=d@entry=0x70a2fc00, verb=verb@entry=4341777) at hw/audio/intel-hda.c:301 #7 0x0060ebbe in intel_hda_corb_run (d=) at hw/audio/intel-hda.c:336 #8 0x0060ebbe in intel_hda_corb_run (d=0x70a2fc00) at hw/audio/intel-hda.c:305 #9 0x00495b99 in memory_region_write_accessor (mr=mr@entry=0x70a307a0, addr=72, value=value@entry=0x7fffeddfe568, size=size@entry=2, shift=, mask=mask@entry=65535, attrs=...) at memory.c:502 #10 0x0049448e in access_with_adjusted_size (addr=addr@entry=72, value=value@entry=0x7fffeddfe568, size=size@entry=2, access_size_min=, access_size_max=, access_fn=access_fn@entry=0x495b10 , mr=0x70a307a0, attrs=...) at memory.c:568 #11 0x004974f3 in memory_region_dispatch_write (mr=mr@entry=0x70a307a0, addr=72, data=, size=2, attrs=attrs@entry=...) at memory.c:1496 #12 0x0042afbc in flatview_write_continue (fv=fv@entry=0x7ffdd36ef5c0, addr=addr@entry=4228186184, attrs=..., buf=buf@entry=0x766c7028 , len=len@entry=2, addr1=, l=, mr=0x70a307a0) at exec.c:3279 #13 0x0042b1d6 in flatview_write (fv=0x7ffdd36ef5c0, addr=addr@entry=4228186184, attrs=attrs@entry=..., buf=buf@entry=0x766c7028 , len=len@entry=2) at exec.c:3318 #14 0x0042e2a6 in address_space_write (as=0xfc5080 , addr=4228186184, attrs=..., buf=buf@entry=0x766c7028 , len=2) at exec.c:3408 #15 0x0042e33a in address_space_rw (as=, addr=, attrs=..., attrs@entry=..., buf=buf@entry=0x766c7028 , len=, is_write=) at exec.c:3419 #16 0x004ac3c6 in kvm_cpu_exec (cpu=cpu@entry=0x70a81140) at accel/kvm/kvm-all.c:2034 #17 0x004812ae in qemu_kvm_cpu_thread_fn (arg=0x70a81140) at cpus.c:1281 #18 0x004812ae in qemu_kvm_cpu_thread_fn (arg=arg@entry=0x70a81140) at cpus.c:1254 #19 0x0089d0eb in qemu_thread_start (args=) at util/qemu-thread-posix.c:502 #20 0x7549319c in start_thread () at /lib64/libpthread.so.0 #21 0x753ba4af in clone () at /lib64/libc.so.6 After some poking around, I think there's something overwriting dev->driver so this switch(dev->driver) statement falls through to abort(): https://git.qemu.org/?p=qemu.git;a=blob;f=audio/audio_template.h;h=1232bb54db0e7073e60e3ccb72c1ed72cf5e3831;hb=131b9a05705636086699df15d4a6d328bb2585e8#l304 Here's why I think so: $ export QEMU_AUDIO_DRV=pa $ gdb /usr/bin/qemu-system-x86_64 (gdb) b qpa_audio_init Breakpoint 1 at 0x79bcb0: file audio/paaudio.c, line 831. (gdb) b audio_get_pdo_in Breakpoint 2 at 0x5ce320: file audio/audio_template.h, line 304. (gdb) run -enable-kvm -cpu Nehalem -machine q35 -device intel-iommu -name Workstation -smp 4 -m 8G -soundhw hda -rtc base=localtime -drive file=workstation-disk0.qcow2,if=virtio,format=qcow2 -drive file=workstation-disk1.qcow2,if=virtio,format=qcow2 -net nic,model=virtio,macaddr=aa:bb:cc:dd:ee:ff -net tap,ifname=tap42 -monitor telnet:127.0.0.1:7043,server,nowait -pidfile wo
[Bug 1833048] Re: Guest Agent get-fsinfo doesn't show ZFS volumes
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1833048 Title: Guest Agent get-fsinfo doesn't show ZFS volumes Status in QEMU: Incomplete Bug description: Calling get-fsinfo on a virtual machine does not include ZFS (zfsonlinux, debian guest tested) volumes. Calling on a system with a single ZFS disk (ZFS as root fs) simply returns '[]', if other disks exist on the guest it only shows these. Expected behaviour: Show file system details like with other fs formats. Tried with debian stretch default qemu-guest-agent package and v4.0.0 from git, compiled locally - result is the same. Host is using QEMU 3.0.1, but that shouldn't matter, right? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1833048/+subscriptions
[Bug 1833204] Re: VM failed to start in nested virtualization with error "KVM: entry failed, hardware error 0x0"
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1833204 Title: VM failed to start in nested virtualization with error "KVM: entry failed, hardware error 0x0" Status in QEMU: Incomplete Bug description: Hi, I have 3 ubuntu nodes provisioned by IaaS. Then I tried to launch VM again in my ubuntu nodes. It's a little strange that VM could be started successfully in two nodes. And always failed in one nodes with error "KVM: entry failed, hardware error 0x0". When using virsh to resume the VM, it failed with following error, virsh # list Id NameState -- 1default_vm-cirros paused virsh # resume default_vm-cirros error: Failed to resume domain default_vm-cirros error: internal error: unable to execute QEMU command 'cont': Resetting the Virtual Machine is required The detailed log from /var/log/libvirt/qemu/default_vm-cirros.log is as below. ``` 2019-06-18 09:55:52.397+: starting up libvirt version: 5.0.0, package: 1.fc28 (Unknown, 2019-01-22-08:04:34, 64723eea657e48d296e6beb0b1be9c4c), qemu version: 3.1.0qemu-3.1.0-4.fc28, kernel: 4.15.0-47-generic, hostname: vm-cirros LC_ALL=C \ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \ HOME=/root \ QEMU_AUDIO_DRV=none \ /usr/bin/qemu-system-x86_64 \ -name guest=default_vm-cirros,debug-threads=on \ -S \ -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-default_vm-cirros/master-key.aes \ -machine pc-q35-3.1,accel=kvm,usb=off,dump-guest-core=off \ -cpu Broadwell-IBRS,vme=on,ss=on,vmx=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc_adjust=on,mpx=on,avx512f=on,avx512cd=on,ssbd=on,xsaveopt=on,abm=on,invpcid=off \ -m 489 \ -realtime mlock=off \ -smp 1,sockets=1,cores=1,threads=1 \ -object iothread,id=iothread1 \ -uuid 0d2a2043-41c0-59c3-9b17-025022203668 \ -no-user-config \ -nodefaults \ -chardev socket,id=charmonitor,fd=22,server,nowait \ -mon chardev=charmonitor,id=monitor,mode=control \ -rtc base=utc \ -no-shutdown \ -boot strict=on \ -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 \ -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \ -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \ -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \ -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \ -device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x0 \ -drive file=/var/run/kubevirt-ephemeral-disks/container-disk-data/default/vm-cirros/disk_containerdisk/disk-image.raw,format=raw,if=none,id=drive-ua-containerdisk,cache=none \ -device virtio-blk-pci,scsi=off,bus=pci.3,addr=0x0,drive=drive-ua-containerdisk,id=ua-containerdisk,bootindex=1,write-cache=on \ -drive file=/var/run/kubevirt-ephemeral-disks/cloud-init-data/default/vm-cirros/noCloud.iso,format=raw,if=none,id=drive-ua-cloudinitdisk,cache=none \ -device virtio-blk-pci,scsi=off,bus=pci.4,addr=0x0,drive=drive-ua-cloudinitdisk,id=ua-cloudinitdisk,write-cache=on \ -netdev tap,fd=24,id=hostua-default,vhost=on,vhostfd=25 \ -device virtio-net-pci,host_mtu=1430,netdev=hostua-default,id=ua-default,mac=16:57:38:cd:57:cb,bus=pci.1,addr=0x0 \ -chardev socket,id=charserial0,fd=26,server,nowait \ -device isa-serial,chardev=charserial0,id=serial0 \ -chardev socket,id=charchannel0,fd=27,server,nowait \ -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ -vnc vnc=unix:/var/run/kubevirt-private/3b22a138-91af-11e9-af36-0016ac101123/virt-vnc \ -device VGA,id=video0,vgamem_mb=16,bus=pcie.0,addr=0x1 \ -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ -msg timestamp=on KVM: entry failed, hardware error 0x0 EAX= EBX= ECX= EDX=000306d2 ESI= EDI= EBP= ESP= EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 9300 CS =f000 9b00 SS = 9300 DS = 9300 FS = 9300 G
[Bug 1833871] Re: qemu-img convert file.vmdk: Invalid footer
** 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/1833871 Title: qemu-img convert file.vmdk: Invalid footer Status in QEMU: Invalid Bug description: Steps to reproduce - Open ESXi 6.5 Web UI - Export OVF - qemu-img convert disk.vmdk disk.qcow2 Error: qemu-img: Could not open './disk-1.vmdk': Invalid footer I found another person having this problem here: https://forum.proxmox.com/threads/error-converting-vmdk-file-to-qcow2-file.38264/ As I guess from the answer, the guy went over to manually copy the flat file from the datastore instead of using the ovf-exported file. Nevertheless, I think this bug should be investigated further and closed. Probably it is just some metadata issue and should not be too hard to fix once the root of the problem is found. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1833871/+subscriptions
[Bug 1835729] Re: GTK display does not support host scale factor
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1835729 Title: GTK display does not support host scale factor Status in QEMU: Incomplete Bug description: In the GNOME desktop environment, for HiDPI displays there is support to upscale everything. This can be set in "System Settings -> Displays -> Scale". I believe this affects GDK in the same way as setting the "GDK_SCALE" environment variable does. When launching `qemu-system-x86_64 ... -display gtk`, this scale factor seems to get lost; the result is that the host window is upscaled and doubled in size, while the guest appears only in the bottom left corner of the UI. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1835729/+subscriptions
[Bug 1835694] Re: hardware-based time keeping
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1835694 Title: hardware-based time keeping Status in QEMU: Incomplete Bug description: Hi all, I hope you're all doing well. As i was looking for a solution for a particular problem in Qemu/KVM virtualization. My issue is that I have a virtual machine that runs well in VMware and when I migrated that to Qemu/KVM-enabled environment, it didn't work! I figured out that under VMware hypervisor, VMware supplies CPU TSC and Performance Counters values to the guest VM with the option "monitor_control.pseudo_perfctr = TRUE" set the vmx configuration file, Ref.: https://www.vmware.com/pdf/vmware_timekeeping.pdf My question is, is there any similar option in Qemu/KVM-enabled environment that I can use to get my VM working the same way as in the VMware environment? I almost tried all options in Qemu with regards to CPU but no avail. To elaborate more, the VM I'm trying to port under Qemu/KVM environment is a an old version of Cisco virtual ASA Firewall. The VM image is actually meant to be run under VMware ESXi and with that "*monitor_control.pseudo_perfctr = TRUE*" option it can also run in Vware Workstation as well. *Yes, this option that makes it run under VMware and if it's removed from the configuration vmx file then the VM boots half way and crashes the same way it crashes under Qemu*. That dictates it's the option in interest that needs to be found in Qemu/KVM. I have a copy of this VM in the below link in case you would like to try its behavior in under VMware. I downloaded it from a youtube previously to test it out: https://drive.google.com/open?id=1SEXws18hoj2sWGk8iFqqH8RpBZsBNpRH Once you power on the VM you can telnet to 127.0.0.1 on port 3000 to see the boot process. If you remove that option i mentioned to you and boot the VM again you'll see the crashing in process. I've converted that vmdk disk images into Qemu disks "qcow2" format and i ran them using the below command line on Ubuntu: /opt/qemu/bin/qemu-system-x86_64 -L -nographic -device e1000-82545em,netdev=net0,mac=50:00:00:6a:00:00 -netdev tap,id=net0,ifname=vunl0_33_0,script=no -device e1000-82545em,netdev=net1,mac=50:00:00:6a:00:01 -netdev tap,id=net1,ifname=vunl0_33_1,script=no -device e1000-82545em,netdev=net2,mac=50:00:00:6a:00:02 -netdev tap,id=net2,ifname=vunl0_33_2,script=no -device e1000-82545em,netdev=net3,mac=50:00:00:6a:00:03 -netdev tap,id=net3,ifname=vunl0_33_3,script=no -machine type=pc-1.0 *-cpu host,migratable=off,invtsc=on,pmu=on* -m 4096 -hda hda.qcow2 -hdb hdb.qcow2 -serial telnet:0.0.0.0:3000,server,nowait -monitor tcp:127.0.0.1:42379,server,nowait -nographic -display none -enable-kvm Once you power on the VM you can telnet to xx.xx.xx.xx 3000 (where the xx IP is the Ubuntu machine IP) to see the crashing in process. You may need to wait for a while for the status messages to appear in the terminal window. I assume it's a cpu issue because in page 9 of the Vmware pdf reference file; it says there are machine instructions become available when this option "*monitor_control.pseudo_perfctr = TRUE*" is enabled: The following machine instructions then become available: InstructionTime ValueReturned rdpmc 0x1 Physical host TSC rdpmc 0x10001 Elapsed real time in ns rdpmc 0x10002 Elapsed apparent time in ns Therefore, I used many of the Qemu cpu options such as these: -cpu host,migratable=no,+invtsc (ref: https://wiki.qemu.org/ChangeLog/2.1) -cpu host, tsc-frequency= (ref: https://lists.gnu.org/archive/ html/qemu-devel/2017-01/msg03555.html) -cpu host,migratable=off,invtsc=true,pmu=true Not sure if i'm hitting the wrong option! The log I'm getting when the VM boots up looks like the following crash happens at the blue colored log: Loading... Starting image verification Hash Computation:100% Done! Computed Hash SHA2: 63c1e8aa9de3d0c6e738dc91be8e1784 5caf64af4cf06cf6a3c5da7200d478dd 938d380d2b10
Re: [PATCH v5 00/17] qapi: static typing conversion, pt3
John Snow writes: > Hi, this series adds static types to the QAPI module. > This is part three, and it focuses on expr.py. > > Environment: > - Python >= 3.6, <= 3.8 * > - mypy >= 0.770 > - pylint >= 2.6.0 > - flake8 > - isort > > Every commit should pass with (from ./scripts/): > - flake8 qapi/ > - pylint --rcfile=qapi/pylintrc qapi/ > - mypy --config-file=qapi/mypy.ini qapi/ > - pushd qapi && isort -c . && popd Series Reviewed-by: Markus Armbruster and queued. Thanks!
Re: [PATCH v3 2/2] block/rbd: Add an escape-aware strchr helper
Hi Connor,
On Wed, Apr 21, 2021 at 04:15:42PM -0500, Connor Kuehl wrote:
On 4/21/21 6:04 AM, Stefano Garzarella wrote:
+static char *qemu_rbd_strchr(char *src, char delim)
+{
+char *p;
+
+for (p = src; *p; ++p) {
+if (*p == delim) {
+return p;
+}
+if (*p == '\\' && p[1] != '\0') {
+++p;
+}
+}
+
+return NULL;
+}
+
IIUC this is similar to the code used in qemu_rbd_next_tok().
To avoid code duplication can we use this new function inside it?
Hi Stefano! Good catch. I think you're right. I've incorporated your
suggestion into my next revision. The only thing I changed was the
if-statement from:
if (end && *end == delim) {
to:
if (end) {
Since qemu_rbd_strchr() will only ever return a non-NULL pointer if it
was able to find 'delim'.
Yeah, definitely better :-)
Thanks,
Stefano
Re: [PATCH v4 2/2] block/rbd: Add an escape-aware strchr helper
On Wed, Apr 21, 2021 at 04:23:43PM -0500, Connor Kuehl wrote: Sometimes the parser needs to further split a token it has collected from the token input stream. Right now, it does a cursory check to see if the relevant characters appear in the token to determine if it should break it down further. However, qemu_rbd_next_tok() will escape characters as it removes tokens from the token stream and plain strchr() won't. This can make the initial strchr() check slightly misleading since it implies qemu_rbd_next_tok() will find the token and split on it, except the reality is that qemu_rbd_next_tok() will pass over it if it is escaped. Use a custom strchr to avoid mixing escaped and unescaped string operations. Furthermore, this code is identical to how qemu_rbd_next_tok() seeks its next token, so incorporate this custom strchr into the body of that function to reduce duplication. Reported-by: Han Han Fixes: https://bugzilla.redhat.com/1873913 Signed-off-by: Connor Kuehl --- v3 -> v4: * Replace qemu_rbd_next_tok() seek loop with qemu_rbd_strchr() since they're identical block/rbd.c| 32 +--- tests/qemu-iotests/231 | 4 tests/qemu-iotests/231.out | 3 +++ 3 files changed, 28 insertions(+), 11 deletions(-) Reviewed-by: Stefano Garzarella
[Bug 1836763] Re: Firebird crashes on qemu-m68k-user with pthread_mutex_init error
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1836763 Title: Firebird crashes on qemu-m68k-user with pthread_mutex_init error Status in QEMU: Incomplete Bug description: Trying to use the Firebird database on qemu-m68k-user with a Debian chroot fails with the database crashing with "ConfigStorage: mutex pthread_mutex_init error, status = 95": (sid-m68k-sbuild)root@epyc:/# apt install firebird3.0-server Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: cpio libip4tc0 Use 'apt autoremove' to remove them. The following additional packages will be installed: firebird3.0-common firebird3.0-common-doc firebird3.0-server-core firebird3.0-utils libfbclient2 libib-util Suggested packages: firebird3.0-doc The following NEW packages will be installed: firebird3.0-common firebird3.0-common-doc firebird3.0-server firebird3.0-server-core firebird3.0-utils libfbclient2 libib-util 0 upgraded, 7 newly installed, 0 to remove and 4 not upgraded. Need to get 4,051 kB of archives. After this operation, 15.9 MB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-common-doc all 3.0.5.33100.ds4-3 [35.3 kB] Get:2 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-common all 3.0.5.33100.ds4-3 [14.5 kB] Get:3 http://ftp.ports.debian.org/debian-ports unstable/main m68k libfbclient2 m68k 3.0.5.33100.ds4-3 [496 kB] Get:4 http://ftp.ports.debian.org/debian-ports unstable/main m68k libib-util m68k 3.0.5.33100.ds4-3 [3,220 B] Get:5 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-server-core m68k 3.0.5.33100.ds4-3 [2,368 kB] Get:6 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-utils m68k 3.0.5.33100.ds4-3 [770 kB] Get:7 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-server m68k 3.0.5.33100.ds4-3 [365 kB] Fetched 4,051 kB in 2s (1,803 kB/s) debconf: delaying package configuration, since apt-utils is not installed E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device) Selecting previously unselected package firebird3.0-common-doc. (Reading database ... 33605 files and directories currently installed.) Preparing to unpack .../0-firebird3.0-common-doc_3.0.5.33100.ds4-3_all.deb ... Unpacking firebird3.0-common-doc (3.0.5.33100.ds4-3) ... Selecting previously unselected package firebird3.0-common. Preparing to unpack .../1-firebird3.0-common_3.0.5.33100.ds4-3_all.deb ... Unpacking firebird3.0-common (3.0.5.33100.ds4-3) ... Selecting previously unselected package libfbclient2:m68k. Preparing to unpack .../2-libfbclient2_3.0.5.33100.ds4-3_m68k.deb ... Unpacking libfbclient2:m68k (3.0.5.33100.ds4-3) ... Selecting previously unselected package libib-util:m68k. Preparing to unpack .../3-libib-util_3.0.5.33100.ds4-3_m68k.deb ... Unpacking libib-util:m68k (3.0.5.33100.ds4-3) ... Selecting previously unselected package firebird3.0-server-core:m68k. Preparing to unpack .../4-firebird3.0-server-core_3.0.5.33100.ds4-3_m68k.deb ... Unpacking firebird3.0-server-core:m68k (3.0.5.33100.ds4-3) ... Selecting previously unselected package firebird3.0-utils. Preparing to unpack .../5-firebird3.0-utils_3.0.5.33100.ds4-3_m68k.deb ... Unpacking firebird3.0-utils (3.0.5.33100.ds4-3) ... Selecting previously unselected package firebird3.0-server. Preparing to unpack .../6-firebird3.0-server_3.0.5.33100.ds4-3_m68k.deb ... Unpacking firebird3.0-server (3.0.5.33100.ds4-3) ... Setting up firebird3.0-common-doc (3.0.5.33100.ds4-3) ... Setting up firebird3.0-common (3.0.5.33100.ds4-3) ... Setting up libib-util:m68k (3.0.5.33100.ds4-3) ... Setting up libfbclient2:m68k (3.0.5.33100.ds4-3) ... Setting up firebird3.0-utils (3.0.5.33100.ds4-3) ... Setting up firebird3.0-server-core:m68k (3.0.5.33100.ds4-3) ... Setting up firebird3.0-server (3.0.5.33100.ds4-3) ... debconf: unable to initialize frontend: Dialog debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be
[Bug 1836136] Re: u-boot: any plans to update u-boot to v2019.07
** 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/1836136 Title: u-boot: any plans to update u-boot to v2019.07 Status in QEMU: Incomplete Bug description: Just want to pulse about the plan to update u-boot binary to latest v2019.07. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1836136/+subscriptions
[Bug 1837347] Re: guest userspace process core dump after raspi2 kernel boot
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1837347 Title: guest userspace process core dump after raspi2 kernel boot Status in QEMU: Incomplete Bug description: Host info: == x86-64, Ubuntu 18.04, QEMU 4.0.0 (downloaded tarball from main site) Guest info: === ARM7l, Raspbian OS off the main raspberry pi site QEMU command: = qemu-system-arm -M raspi2 -kernel bootpart/kernel7.img -dtb bootpart/bcm2709-rpi-2-b.dtb -drive file=2019-07-10-raspbian-buster.img,format=raw,if=sd -append "rw earlyprintk console=ttyAMA0,115200 fsck.repair=yes rootwait memtest=1 loglevel=8 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" -serial stdio kernel7.img and bcm2709-rpi-2-b.dtb were obtained by the following commands: guestfish --ro -a 2019-07-10-raspbian-buster.img -m /dev/sda1 > copy-out / bootpart/ > quit Output: === https://pastebin.com/fL1eXhV0 References: === https://translatedcode.wordpress.com/2016/11/03/installing-debian-on-qemus-32-bit-arm-virt-board/ https://translatedcode.wordpress.com/2018/04/25/debian-on-qemus-raspberry-pi-3-model/ The core dump error can occur at both times, before logging in and after logging in, in this case I have given the output after logging in to show the initial processes running. Also please let me know if I using any kernel flags incorrectly To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1837347/+subscriptions
[Bug 1837851] Re: hv-tlbflush malfunctions on Intel host CPUs with neither EPT nor VPID (qemu-kvm)
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1837851 Title: hv-tlbflush malfunctions on Intel host CPUs with neither EPT nor VPID (qemu-kvm) Status in QEMU: Incomplete Bug description: Enabling hv-tlbflush on older hosts using Intel CPUs supporting VT-x but neither EPT nor VPID will lead to bluescreens on the guest. It seems KVM only checks if EPT is available, and if it isn't it forcibly uses VPID. If that's *also* not available, it defaults to basically a no-op hypercall, though windows is expecting the TLB to be flushed. hv-tlbflush is pretty useless on machines not supporting these extensions anyway (only reasonably fix I can see would be to flush the *entire* TLB on tlbflush hypercall in KVM (i.e. a kernel fix), but that would remove any performance benefits), so I would suggest some kind of preliminary check and warning/error if hv-tlbflush is specified on such a host. All CPUs mentioned in this thread[0] are confirmed to be affected by the bug, and I have successfully reproduced it on an Intel Core2Duo E8500. [0] https://forum.proxmox.com/threads/windows-guest-bluescreen-with- proxmox-6.56053/ To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1837851/+subscriptions
[Bug 1835732] Re: GTK display zoom in, zooms infinitely
** 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/1835732 Title: GTK display zoom in, zooms infinitely Status in QEMU: Incomplete Bug description: The zoom in feature in the "View" menu of the gtk frontend (launch qemu with -display gtk), seems to be very broken. If I hit the zoom in feature, it first zooms in. Then, it zooms in again. Every subsequent second that passes, it zooms in again, until it eventually eats up too much host resources and freezes the host desktop. I have seen this with 3.1.0 (Debian 1:3.1+dfsg-8~deb10u1), and also with a locally built 4.0, My colleague also confirms having seen the issue with 3.1.0 (Debian 1:3.1+dfsg-8). To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1835732/+subscriptions
[Bug 1836855] Re: virtio_scsi_ctx_check failed when detach virtio_scsi disk
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1836855 Title: virtio_scsi_ctx_check failed when detach virtio_scsi disk Status in QEMU: Incomplete Bug description: I found a problem that virtio_scsi_ctx_check failed when detaching virtio_scsi disk. The bt is below: (gdb) bt #0 0xb02e1bd0 in raise () from /lib64/libc.so.6 #1 0xb02e2f7c in abort () from /lib64/libc.so.6 #2 0xb02db124 in __assert_fail_base () from /lib64/libc.so.6 #3 0xb02db1a4 in __assert_fail () from /lib64/libc.so.6 #4 0x004eb9a8 in virtio_scsi_ctx_check (d=d@entry=0xc70d790, s=, s=) at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:243 #5 0x004ec87c in virtio_scsi_handle_cmd_req_prepare (s=s@entry=0xd27a7a0, req=req@entry=0xafc4b90) at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:553 #6 0x004ecc20 in virtio_scsi_handle_cmd_vq (s=0xd27a7a0, vq=0xd283410) at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:588 #7 0x004eda20 in virtio_scsi_data_plane_handle_cmd (vdev=0x0, vq=0xae7a6f98) at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi-dataplane.c:57 #8 0x00877254 in aio_dispatch (ctx=0xac61010) at util/aio-posix.c:323 #9 0x008773ec in aio_poll (ctx=0xac61010, blocking=true) at util/aio-posix.c:472 #10 0x005cd7cc in iothread_run (opaque=0xac5e4b0) at iothread.c:49 #11 0x0087a8b8 in qemu_thread_start (args=0xac61360) at util/qemu-thread-posix.c:495 #12 0x008a04e8 in thread_entry_for_hotfix (pthread_cb=0x0) at uvp/hotpatch/qemu_hotpatch_helper.c:579 #13 0xb041c8bc in start_thread () from /lib64/libpthread.so.0 #14 0xb0382f8c in thread_start () from /lib64/libc.so.6 assert(blk_get_aio_context(d->conf.blk) == s->ctx) failed. I think this patch (https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a6f230c8d13a7ff3a0c7f1097412f44bfd9eff0b) introduce this problem. commit a6f230c8d13a7ff3a0c7f1097412f44bfd9eff0b move blockbackend back to main AioContext on unplug. It set the AioContext of SCSIDevice to the main AioContex, but s->ctx is still the iothread AioContext. Is this a bug? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1836855/+subscriptions
[Bug 1835839] Re: qemu-user: $0 incorrectly always reports absolute path
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1835839 Title: qemu-user: $0 incorrectly always reports absolute path Status in QEMU: Incomplete Bug description: We just ran into an issue with the Perl package on Debian/m68k when being built with qemu-user [1]. The problem can be boiled down to qemu-user always reporting absolute paths for the shell variable $0 no matter on how the command was invoked. A simple reproducer is this: On normal system (no emulation): root@nofan:~> sh -c 'echo $0' sh root@nofan:~> On qemu-user: (sid-m68k-sbuild)root@nofan:/# sh -c 'echo $0' /bin/sh (sid-m68k-sbuild)root@nofan:/# > [1] https://lists.debian.org/debian-68k/2019/07/msg7.html To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1835839/+subscriptions
[Bug 1837909] Re: test-char fails if host has no network interfaces
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1837909 Title: test-char fails if host has no network interfaces Status in QEMU: Incomplete 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
[Bug 1838066] Re: unexpected error: raw_reconfigure_getfd(): qemu-system-x86_64: Could not reopen file
Assuming this has been fixed according to Max' comment. If not, please re-open. ** 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/1838066 Title: unexpected error: raw_reconfigure_getfd(): qemu-system-x86_64: Could not reopen file Status in QEMU: Fix Released Bug description: Unexpected error in raw_reconfigure_getfd() at block/file-posix.c:923: qemu-system-x86_64: Could not reopen file: Permission denied Aborted Is what i sometimes (only) get, mostly for Linux guests i'd say (Arch just a few moments ago). This is on CRUX-Linux, thus a self-compiled qemu 4.0.0 with default recipe, without special compiler flags (-O2 -march=x86-64 -pipe) on an Intel i5 laptop. But what i do is running this via sudo: sudo='sudo --preserve-env=VMNAME,VMADDR' runas='-runas vm -chroot .' fi VMADDR=$addr VMNAME=$vmname export VMADDR VMNAME eval exec $sudo qemu-system-x86_64 -name $vmname $runas \ $host $accel $display $net $vmcustom $vmimg $redir the last run ends up like (via sudo) qemu-system-x86_64 -name arch-2019 -runas vm -chroot . -cpu host -m size=1984 -smp cpus=2 -enable-kvm -accel accel=kvm,thread=multi -display curses -net nic,netdev=net0,macaddr=.. -netdev tap,id=net0,script=./.ifup.sh,downscript=./.ifdown.sh,ifname=vm_arch-2019 vm is a user effectively living in the chroot only without any rights anywhere. Hope this helps, thanks a lot for qemu!! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1838066/+subscriptions
[Bug 1839294] Re: Latest Installer (qemu-w64-setup-20190807.exe) for windows immediately deletes installed files at the very end of the installation
Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? ** 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/1839294 Title: Latest Installer (qemu-w64-setup-20190807.exe) for windows immediately deletes installed files at the very end of the installation Status in QEMU: Incomplete Bug description: This happens on Windows 10 with the latest installer for 64 bit Windows: qemu-w64-setup-20190807.exe On install it will create the files and go through all the typical functions of installing the software, at the very end step it will then delete all files the installer created. I looked for logs to see when was going on so I ran the installation in Sandboxie and was able to retain all the installed files but I couldn't find a log for the installer. Here is a screenshot of it deleting all the files at the end of the process. https://imgur.com/BWiTA38 If goes too fast for me to see what is written in the text console otherwise I would post more information but this is all I have. It does not give any error or any other information at completion. This error does not occur in the earlier release: qemu-w64-setup-20190731.exe To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1839294/+subscriptions
[Bug 1839367] Re: Wrong interrupts generated for I.MX6 FEC controller
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1839367 Title: Wrong interrupts generated for I.MX6 FEC controller Status in QEMU: Incomplete Bug description: The imx_eth_update function in hw/net/imx_fec.c has the following comment (https://github.com/qemu/qemu/blob/864ab314f1d924129d06ac7b571f105a2b76a4b2/hw/net/imx_fec.c#L421-L445): /* * Previous versions of qemu had the ENET_INT_MAC and ENET_INT_MAC * interrupts swapped. This worked with older versions of Linux (4.14 * and older) since Linux associated both interrupt lines with Ethernet * MAC interrupts. Specifically, * - Linux 4.15 and later have separate interrupt handlers for the MAC and * timer interrupts. Those versions of Linux fail with versions of QEMU * with swapped interrupt assignments. * - In linux 4.14, both interrupt lines were registered with the Ethernet * MAC interrupt handler. As a result, all versions of qemu happen to * work, though that is accidental. * - In Linux 4.9 and older, the timer interrupt was registered directly * with the Ethernet MAC interrupt handler. The MAC interrupt was * redirected to a GPIO interrupt to work around erratum ERR006687. * This was implemented using the SOC's IOMUX block. In qemu, this GPIO * interrupt never fired since IOMUX is currently not supported in qemu. * Linux instead received MAC interrupts on the timer interrupt. * As a result, qemu versions with the swapped interrupt assignment work, * albeit accidentally, but qemu versions with the correct interrupt * assignment fail. * * To ensure that all versions of Linux work, generate ENET_INT_MAC * interrrupts on both interrupt lines. This should be changed if and when * qemu supports IOMUX. */ Unfortunately, this behavior causes the QNX Sabrelite BSP (http://blackberry.qnx.com/en/developers/bsp) to hang on ethernet initialization. This is caused by the fact that QEMU is firing the ENET_INT_TS_TIMER timer interrupt unexpectedly (when the ENET_INT_MAC flag is set). The BSP functions correctly on the actual hardware, but it is unable to handle the deliberately incorrect interrupt firing by QEMU. From reading the comment, it appears that this behavior is necessary to support certain versions of Linux. However, it would be very useful to be able to restore the correct interrupt behavior (possibly via a command-line flag). To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1839367/+subscriptions
[Bug 1838465] Re: qemu-system-x86_64 kernel panic 30% of the time starting up VM
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1838465 Title: qemu-system-x86_64 kernel panic 30% of the time starting up VM Status in QEMU: Incomplete Bug description: I have created a Fedora Core 5 x86_64 VM image. When I run the image using QEMU on Windows the VM hangs while loading the kernel about 30% of the time. I am trying to use this VM with a CI software, looking at the history the build failed 27 out of 79 attempts. QEMU 3.0.0 is installed on the CI machine. I have tried using the exact same image using QEMU on Linux (Ubuntu) and found the image boot successful every time (40+ attempts). The VM image is fairly old it was created using QEMU 0.11.1. I have tried multiple versions on QEMU on windows; 0.11.1, 2.12.1, and 3.0.0 all of them fail randomly. I can reproduce the issue on several different Windows 10 computers. The command I am using to start the VM is “qemu-system-x86_64.exe -cpu qemu64 -smp cores=2 -device e1000,netdev=net0 -boot menu=off -m 1G -drive `"file=C:\qimages\Fedora-Core-5-x64.qcow2,index=0,media=disk`" -snapshot -netdev user,id=net0,hostfwd=tcp::10022-:22” I can provide the qcow image but it is somewhat large coming it at 4.15GB so I’m not sure what would be the best way to transfer it. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1838465/+subscriptions
[Bug 1838228] Re: Slirp Broadcast traffic
The ticket in the libslirp tracker has been closed a year ago, so I think we can close this ticket here, too. ** 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/1838228 Title: Slirp Broadcast traffic Status in QEMU: Fix Released 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
[Bug 1838390] Re: vmx_write_mem: mmu_gva_to_gpa failed when using hvf
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1838390 Title: vmx_write_mem: mmu_gva_to_gpa failed when using hvf Status in QEMU: Incomplete Bug description: Installed qemu 4.0.0 by homebrew, used below commands: 1. qemu-img create -f raw arch-vm.img 100G 2. qemu-system-x86_64 -show-cursor -only-migratable -nodefaults -boot order=d -cdrom archlinux-2019.07.01-x86_64.iso -cpu host -device virtio-keyboard -device virtio-mouse -device virtio-tablet -drive file=arch-vm.img,format=raw,if=virtio -m 4096 -machine q35,accel=hvf,vmport=off -nic user,ipv6=off,model=virtio -smp 4,sockets=1,cores=2,threads=2 -soundhw hda -vga virtio Displayed bootloader menu successfully, select "Boot Arch Linux" then crashed with message: vmx_write_mem: mmu_gva_to_gpa 91953b54 failed. Use tcg accelerator has no problem but very slow. See attachment for full crash report. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1838390/+subscriptions
[Bug 1843711] Re: qemu-xhci device should detect if libusb host supports streams
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1843711 Title: qemu-xhci device should detect if libusb host supports streams Status in QEMU: Incomplete Bug description: When using USB passthrough with the qemu-xhci (and nec-usb-xhci), streams are enabled by default, but if the host xHCI controller doesn't support them, it will trigger hard-to-debug UAS guest errors. This should be possible to detect since the kernel returns ENOSYS (errno 38) when xhci host controller does not support streams: libusb: error [do_streams_ioctl] streams-ioctl failed error -1 errno 38 qemu: libusb_alloc_streams: -99 [OTHER] Maybe libusb should return a dedicated error instead of LIBUSB_ERROR_OTHER in this case, but qemu does not handle any other error code anyway. Just trying to enable streams before enabling them in qemu should do it. I don't know if it should be done in hcd-xhci.c, host-libusb.c or elsewhere, but this would be detectable at launch instead of a static option true/false, maybe a ternary with auto would be better. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1843711/+subscriptions
[Bug 1843941] Re: RBD Namespaces are not supported
Patch had been included here: https://gitlab.com/qemu-project/qemu/-/commit/19ae9ae01471552 ** 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/1843941 Title: RBD Namespaces are not supported Status in QEMU: Fix Released Bug description: Ceph Nautilus (v14.2.0) introduced the Namespaces concept for RADOS Block Devices. This provides a logical separation within a RADOS Pool for RBD images which enables granular access control. See https://docs.ceph.com/docs/nautilus/releases/nautilus/ for additional details. librados and librbd support this, however qemu does not. The rbd man page defines how rbd images within a namespace can be referenced. https://docs.ceph.com/docs/nautilus/man/8/rbd/#image-snap-group-and- journal-specs Adding support for RBD namespaces would be beneficial for security and reducing the impact of a hypervisor being compromised and putting an entire Ceph pool or cluster at risk. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1843941/+subscriptions
[Bug 1843852] Re: QEMU does not express a dependency on perl-Test-Harness
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1843852 Title: QEMU does not express a dependency on perl-Test-Harness Status in QEMU: Incomplete Bug description: This is a minor thing; in Fedora you can install most of the developer dependencies by issuing something like `dnf builddep qemu-kvm` and this takes care of just about everything such that you can run ./configure and make. For "make check" though, configure doesn't catch that you'll need perl-Test-Harness; so it fails halfway through the check routine, and you'll see this: ``` Can't locate TAP/Parser.pm in @INC (you may need to install the TAP::Parser module) (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at ./scripts/tap-driver.pl line 30. BEGIN failed--compilation aborted at ./scripts/tap-driver.pl line 30. make: *** [/home/jhuston/src/qemu/tests/Makefile.include:905: check-unit] Error 2 ``` I'm not sure how we should express this dependency; it shouldn't be a requirement for building, but it IS a dependency for testing. We probably ought not let users skip the qapi tests just because they don't have the perl requirement met. (And, separately, the Fedora package should list this as a builddep, but that's not an issue for here.) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1843852/+subscriptions
Re: [PATCH 1/3] qga-win: Increase VSS freeze timeout to 60 secs instead of 10
ping On Mon, Apr 5, 2021 at 4:14 PM Basil Salman wrote: > Currently Requester freeze times out after 10 seconds, while > the default timeout for Writer Freeze is 60 seconds. according to > VSS Documentation [1]. > [1]: > https://docs.microsoft.com/en-us/windows/win32/vss/overview-of-processing-a-backup-under-vss > > Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1909073 > > Signed-off-by: Basil Salman > Signed-off-by: Basil Salman > --- > qga/vss-win32/requester.cpp | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/qga/vss-win32/requester.cpp b/qga/vss-win32/requester.cpp > index 5378c55d23..940a2c8f55 100644 > --- a/qga/vss-win32/requester.cpp > +++ b/qga/vss-win32/requester.cpp > @@ -18,7 +18,7 @@ > #include > > /* Max wait time for frozen event (VSS can only hold writes for 10 > seconds) */ > -#define VSS_TIMEOUT_FREEZE_MSEC 1 > +#define VSS_TIMEOUT_FREEZE_MSEC 6 > > /* Call QueryStatus every 10 ms while waiting for frozen event */ > #define VSS_TIMEOUT_EVENT_MSEC 10 > -- > 2.17.2 > >
[Bug 1843651] Re: m68k fpu bug
The QEMU project is currently considering to move its bug tracking to
another system. For this we need to know which bugs are still valid
and which could be closed already. Thus we are setting older bugs to
"Incomplete" now.
If you still think this bug report here is valid, then please switch
the state back to "New" within the next 60 days, otherwise this report
will be marked as "Expired". Or please mark it as "Fix Released" if
the problem has been solved with a newer version of QEMU already.
Thank you and sorry for the inconvenience.
** 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/1843651
Title:
m68k fpu bug
Status in QEMU:
Incomplete
Bug description:
On gcc123 cfarm machine,
I was testing m68k executables generated by Free Pascal Compiler.
muller@gcc123:~/pas/check$ cat inf.pp
function get_double(x : double):double;
begin
get_double:=x;
end;
var
y : double;
py : pbyte;
i : byte;
begin
y:=1.0/0.0;
py:=@y;
{$ifdef ENDIAN_LITTLE}
write('little endian y=');
for i:=7 downto 0 do
{$else not ENDIAN_LITTLE}
write('big endian y=');
for i:=0 to 7 do
{$endif}
write(hexstr(py[i],2));
writeln;
y:=get_double(y)+1;
{$ifdef ENDIAN_LITTLE}
write('little endian y=');
for i:=7 downto 0 do
{$else not ENDIAN_LITTLE}
write('big endian y=');
for i:=0 to 7 do
{$endif}
write(hexstr(py[i],2));
writeln;
end.
muller@gcc123:~/pas/check$ ppc68k inf
Free Pascal Compiler version 3.3.1-r20:42973M [2019/09/11] for m68k
Copyright (c) 1993-2019 by Florian Klaempfl and others
Target OS: Linux for m68k
Compiling inf.pp
Assembling program
Linking inf
33 lines compiled, 0.1 sec
muller@gcc123:~/pas/check$ ./inf
big endian y=7FF0
big endian y=7FFF
muller@gcc123:~/pas/check$ qemu-m68k ./inf
big endian y=7FF0
big endian y=7FFF
muller@gcc123:~/pas/check$ ~/sys-root/bin/qemu-m68k ./inf
qemu-m68kqemu-m68k-fixed
muller@gcc123:~/pas/check$ ~/sys-root/bin/qemu-m68k-fixed ./inf
big endian y=7FF0
big endian y=7FF0
~/sys-root/bin/qemu-m68k is 4.1.0 release,
~/sys-root/bin/qemu-m68k-fixed is the same source with a unique change:
gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h:214:#if defined(TARGET_M68K)
gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-215-#define
floatx80_infinity_low LIT64(0x)
gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-216-#else
gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-217-#define
floatx80_infinity_low LIT64(0x8000)
gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-218-#endif
the M68K branch value is set to the same value as the other branch.
The problem of the M68K specific floatx86_infinity_low values
is that is enters in conflict with
muller@gcc123:~/pas/check$ grep -nA6 invalid_enc
/home/muller/gnu/qemu/qemu-4.1.0/include/fpu/softfloat.h
752:static inline bool floatx80_invalid_encoding(floatx80 a)
753-{
754-return (a.low & (1ULL << 63)) == 0 && (a.high & 0x7FFF) != 0;
755-}
And thus the m68k variant of floatx80 representing +Infinity is
considered as an invalid encoding, and thus converted into a NaN
7FFF
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1843651/+subscriptions
[Bug 1843795] Re: 'mtfsf' instruction can clear FI incorrectly
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1843795 Title: 'mtfsf' instruction can clear FI incorrectly Status in QEMU: Incomplete Bug description: Using mtfsf instruction can clear the FPSCR FI bit incorrectly. This code snippet exhibits the issue: -- fpscr.ll = 0x1fff; __builtin_mtfsf (0b, fpscr.d); fpscr.d = __builtin_mffs (); -- On POWER9 hardware: mffs: FPSCR = 0x77ff On qemu (git master; "-cpu POWER9"): -- $ ./mtfsf mffs: FPSCR = 0x7ffd -- Two differences: bit 52: "reserved", so maybe a "don't care" case bit 46: "FI" $ git log -1 master commit 89ea03a7dc83ca36b670ba7f787802791fcb04b1 Merge: 019217c 2531164 Author: Peter Maydell Date: Mon Sep 9 09:48:34 2019 +0100 I tracked the clear is coming from do_float_check_status, likely the one in gen_mtfsf, but then I get lost figuring out what _should_ be happening. :-/ Test attached. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1843795/+subscriptions
[Bug 1848244] Re: QEMU KVM IGD SandyBridge Passthrough crash
I'm closing this now since there seems to be a workaround available and nobody updated this bug in the past 1.5 years anymore ** Changed in: qemu Status: New => Won't 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/1848244 Title: QEMU KVM IGD SandyBridge Passthrough crash Status in QEMU: Won't Fix Bug description: I try to passthrough my Intel GPU with this command: qemu-system-x86_64 -nodefaults -parallel none -k de -rtc base=localtime -serial unix:/run/qemu/win7-serial.sock,server,nowait -monitor unix:/run/qemu/win7-monitor.sock,server,nowait -netdev user,id=net0 -device virtio-net-pci,netdev=net0,mac=52:54:00:00:00:07 -device vfio-pci,host=:00:02.0,addr=0x2 -device vfio- pci,host=:00:1b.0 -device virtio-keyboard-pci -device virtio- mouse-pci -object input-linux,id=kbd1,evdev=/dev/input/by- path/pci-:00:1a.0-usb-0:1.2.2:1.2-event-kbd,grab_all=on,repeat=on -object input-linux,id=mouse1,evdev=/dev/input/by- path/pci-:00:1a.0-usb-0:1.2.2:1.2-event-mouse -enable-kvm -cpu host -smp 4,sockets=1,cores=4,threads=1 -vga none -display none -m 2g -device virtio-blk-pci,drive=boot,bootindex=1 -drive file=/opt/vm/qcow2/win7.qcow2,format=qcow2,if=none,id=boot This ONLY works if i remove "-enable-kvm" else the windows (7 and 10) boot crashes in bluescreen "stop 0x003b" (probably while loading the intel gpu driver (intel graphics 3000). The system is an older ThinkPad T420 with Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz. CMDLINE: BOOT_IMAGE=/vmlinuz-linux root=LABEL=root rw ipv6.disable=0 net.ifnames=0 intel_iommu=on iommu=pt video=LVDS-1:d To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1848244/+subscriptions
[Bug 1847467] Re: qemu-x86_64 segment prefixes error
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1847467 Title: qemu-x86_64 segment prefixes error Status in QEMU: Incomplete Bug description: qemu-x86_64 version 4.1.0 (qemu-x86_64 version 4.0.0 also have the issue) In 64-bit mode (x86_64) the DS, ES, SS or CS segment prefixes should be ignored; qemu-x86_64 does not ignore them. example: an x86_64 instructions preceded by FS DS (0x64 0x26) segment prefixes have the linear address of its memory reference flat-mapped (as if DS was in action) whereas it should be FS-mapped (offset by FS_base, because the DS, ES, SS or CS are just ignored). I attach a small C++ program that shows this discrepancy. $ ./sample I'm not in QEMU $ qemu-x86_64 ./sample I'm in QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1847467/+subscriptions
[Bug 1845185] Re: Cannot build qemu utils (qemu-img.exe, qemu-edid.exe, qemu-io.exe) statically with MSYS64 on Windows because intl and iconv libs are not loaded
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1845185 Title: Cannot build qemu utils (qemu-img.exe, qemu-edid.exe, qemu-io.exe) statically with MSYS64 on Windows because intl and iconv libs are not loaded Status in QEMU: Incomplete Bug description: Using MSYS2 and mingw32 instructions from https://wiki.qemu.org/Hosts/W32#Native_builds_with_MSYS2, I could not statically build the qemu-utils using the latest qemu master branch. Steps to reproduce the issue: 1. Install MSYS2 on a Windows 10 x64 box 2. Install required mingw64 toolchain: pacman -S base-devel mingw-w64-x86_64-toolchain git python mingw-w64-x86_64-glib2 mingw64/mingw-w64-x86_64-gtk3 mingw64/mingw-w64-x86_64-SDL2 3. clone qemu 4. Run configure for static build for the tools only ./configure --disable-user --disable-system --disable-docs --enable-tools --disable-guest-agent --disable-capstone --disable-sheepdog --enable-debug --static # I had to remove sheepdog, capstone and guest agent because other errors popped out, but let's not go in the rabbit hole. 5. Run 'make -j'. the following errors appeared, signaling that intl lib is not loaded. If I add intl lib, iconv lib needs to be loaded too. make: *** [/home/ader1990/qemu/rules.mak:124: qemu-img.exe] Error 1 make: *** Waiting for unfinished jobs C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x1522): undefined reference to `libintl_sprintf' C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x154f): undefined reference to `libintl_sprintf' C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x157e): undefined reference to `libintl_sprintf' C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x15ad): undefined reference to `libintl_sprintf' C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x15dc): undefined reference to `libintl_sprintf' C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x1622): more undefined references to `libintl_sprintf' follow C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x43): undefined reference to `libintl_textdomain' C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x52): undefined reference to `libintl_gettext' C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x203): undefined reference to `libintl_bindtextdomain' C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x21e): undefined reference to `libintl_bind_textdomain_codeset' C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x2c1): undefined reference to `libintl_dgettext' C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x4e1): undefined reference to `libintl_dcgettext' C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x53a): undefined reference to `libintl_dngettext' Patch to fix the issue (added intl and iconv to the libs): diff --git a/configure b/configure index 30aad233d1..e2ab8ef026 100755 --- a/configure +++ b/configure @@ -920,7 +920,7 @@ if test "$mingw32" = "yes" ; then DSOSUF=".dll" # MinGW needs -mthreads for TLS and macro _MT. QEMU_CFLAGS="-mthreads $QEMU_CFLAGS" - LIBS="-lwinmm -lws2_32 -liphlpapi $LIBS" + LIBS="-lwinmm -lws2_32 -liphlpapi -lintl -liconv $LIBS" write_c_skeleton; if compile_prog "" "-liberty" ; then LIBS="-liberty $LIBS" To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1845185/+subscriptions
[Bug 1844053] Re: task blocked for more than X seconds - events drm_fb_helper_dirty_work
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1844053 Title: task blocked for more than X seconds - events drm_fb_helper_dirty_work Status in QEMU: Incomplete Bug description: I've had bunches of these errors on 9 different boots, between 2019-08-21 and now, with Arch host and guest, from linux 5.1.16 to 5.2.14 on host and guest, with QEMU 4.0.0 and 4.1.0. spice 0.14.2, spice-gtk 0.37, spice-protocol 0.14.0, virt-viewer 8.0. I've been fighting with some other issues related to a 5.2 btrfs regression, a QEMU qxl regression (see bug 1843151) which I ran into when trying to temporarily abandon virtio-vga, and I haven't paid enough attention to what impact specifically this virtio_gpu issue has on the system In journalctl, I can see I often rebooted minutes after they occurred, but sometimes much later. That must mean whenever I saw it happen that I rebooted the VM, or potentially it impacted functionality of the system. Please let me know if and how I can get more information for you if needed. I've replicated this on both a system with integrated ASPEED video, and on an AMD Vega 64 running amdgpu. As an example, I have one boot which reported at 122 seconds, 245, 368, 491, 614, 737, 860, 983, 1105, 1228, then I rebooted. I have another that reported 122/245/368/491/614/737, went away for 10 minutes, then started reporting again 122/245/368/491, and went away. Then, I rebooted about 20 hours later. Host system has no graphical impact when this happens, and logs nothing in its journalctl. Guest is tty mode only, with kernel argument "video=1280x1024". No x server. == INFO: task kworker/0:1:15 blocked for more than 122 seconds. Not tainted 5.2.14-1 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/0:1 D015 2 0x84000 Workqueue: events drm_fb_helper_dirty_work [drm_kms_helper] Call Trace: ? __schedule+0x27f/0x6d0 schedule+0x3d/0xc0 virtio_gpu_queue_fenced_ctrl_buffer+0xa1/0x130 [virtio_gpu] ? wait_woken+0x80/0x80 virtio_gpu_surface_dirty+0x2a5/0x300 [virtio_gpu] drm_fb_helper_dirty_work+0x156/0x160 [drm_kms_helper] process_one_work+0x19a/0x3b0 worker_tread+0x50/0x3a0 kthread+0xfd/0x130 ? process_one_work+0x3b0/0x3b0 ? kthread_park+0x80/0x80 ret_from_fork+0x35/0x40 == /usr/bin/qemu-system-x86_64 \ -name vm,process=qemu:vm \ -no-user-config \ -nodefaults \ -nographic \ -uuid \ -pidfile \ -machine q35,accel=kvm,vmport=off,dump-guest-core=off \ -cpu SandyBridge-IBRS \ -smp cpus=4,cores=2,threads=1,sockets=2 \ -m 4G \ -drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd \ -drive if=pflash,format=raw,file=/var/qemu/efivars/vm.fd \ -monitor telnet:localhost:8000,server,nowait,nodelay \ -spice unix,addr=/tmp/spice.vm.sock,disable-ticketing \ -device ioh3420,id=pcie.1,bus=pcie.0,slot=0 \ -device virtio-vga,bus=pcie.1,addr=0 \ -usbdevice tablet \ -netdev bridge,id=network0,br=br0 \ -device virtio-net-pci,netdev=network0,mac=F4:F6:34:F6:34:2d,bus=pcie.0,addr=3 \ -device virtio-scsi-pci,id=scsi1 \ -drive driver=raw,node-name=hd0,file=/dev/lvm/vm,if=none,discard=unmap,cache=none,aio=threads To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1844053/+subscriptions
[Bug 1847861] Re: Guest stuttering under high disk IO (virtio)
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1847861 Title: Guest stuttering under high disk IO (virtio) Status in QEMU: Incomplete Bug description: Performing io intensive tasks on virtualized Windows causes the system to visually stutter. I can often reproduce the problem by running fio on windows: fio --randrepeat=1 --ioengine=windowsaio --direct=1 --gtod_reduce=1 --name=test --filename=\\.\PhysicalDrive0 --bs=4k --iodepth=128 --size=4G --readwrite=randread While the fio command is running, moving the mouse pointer will be be laggy. The stuttering does not appear with iodepth <= 32 . The stuttering also manifests while playing games, the music and video pauses for a fraction of second in a playable but disturbing way. Here are my system specs: Host OS: archlinux Guest OS: Windows 10 Enterprise qemu version: qemu-git 8:v4.1.0.r1378.g98b2e3c9ab-1 (from AUR, compiled with -march=native) CPU: AMD Ryzen Threadripper 1900X 8-Core Processor Huge Pages: vm.nr_hugepages=4128 Disk: nvme type=raw, io=threads bus=virtio GPU (passthrough): Radeon RX 570 Here are some fio test results on my windows guest: [size=512M,iodepth=1 -> min=30k,avg=31k,stddev=508] [size=2G,iodepth=8 -> min=203k,avg=207k,stddev=2.3k] [size=2G,iodepth=16 -> min=320k,avg=330k,stddev=4.3k] [size=4G,iodepth=32 -> min=300k,avg=310k,stddev=4.8k] [size=4G,iodepth=64 -> min=278k,avg=366k,stddev=68.6k] -> STUTTER [size=4G,iodepth=64 -> min=358k,avg=428k,stddev=52.6k] -> STUTTER [size=4G,iodepth=128 -> min=92k,avg=217k,stddev=185k] -> STUTTER [size=4G,iodepth=128 -> min=241k,avg=257k,stddev=14k] -> same config as above, but no stuttering The min and avg values are the bandwidth values reported in KB/s by fio. You can see that, when the stuttering occurs, the stardard deviation is high and the minimum bandwidth is way below the average. Additional note: the bandwidth reported with `fio` on my linux host is about 2x the one reported in the guest: sudo fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/dev/nvme0n1 --bs=4k --iodepth=64 --size=512M --readwrite=randread read: IOPS=279k, BW=1092MiB/s (1145MB/s)(512MiB/469msec) Moreover, during the fio tests on the guest I've noticed that the CPU usage on the host is very high (around 450%) whereas on the guest is only 10% To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1847861/+subscriptions
[Bug 1847440] Re: ppc64le: KVM guest fails to boot with an error `virtio_scsi: probe of virtio1 failed with error -22` on master
The SLOF fix has been merged 1.5 years ago, so I assume this can be
marked as fixed now.
** 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/1847440
Title:
ppc64le: KVM guest fails to boot with an error `virtio_scsi: probe of
virtio1 failed with error -22` on master
Status in QEMU:
Fix Released
Bug description:
PowerPC KVM Guest fails to boot on current qemu master, bad commit:
e68cd0cb5cf49d334abe17231a1d2c28b846afa2
Env:
HW: IBM Power9
Host Kernel: 5.4.0-rc2-00038-ge3280b54afed
Guest Kernel: 4.13.9-300.fc27.ppc64le
Qemu: https://github.com/qemu/qemu.git (master)
Libvirt: 5.4.0
Guest boot gets stuck:
...
[ OK ] Mounted Kernel Configuration File System.
[7.598740] virtio-pci :00:01.0: enabling device ( -> 0003)
[7.598828] virtio-pci :00:01.0: virtio_pci: leaving for legacy driver
[7.598957] virtio-pci :00:02.0: enabling device ( -> 0003)
[7.599017] virtio-pci :00:02.0: virtio_pci: leaving for legacy driver
[7.599123] virtio-pci :00:04.0: enabling device ( -> 0003)
[7.599182] virtio-pci :00:04.0: virtio_pci: leaving for legacy driver
[7.620620] synth uevent: /devices/vio: failed to send uevent
[7.620624] vio vio: uevent: failed to send synthetic uevent
[ OK ] Started udev Coldplug all Devices.
[7.624559] audit: type=1130 audit(1570610300.990:5): pid=1 uid=0
auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-udev-trigger
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'
[ OK ] Reached target System Initialization.
[ OK ] Reached target Basic System.
[ OK ] Reached target Remote File Systems (Pre).
[ OK ] Reached target Remote File Systems.
[7.642961] virtio_scsi: probe of virtio1 failed with error -22
[ *** ] A start job is running for dev-disk…21b3519a80.device (14s / no
limit)
...
git bisect, yielded a bad commit
[e68cd0cb5cf49d334abe17231a1d2c28b846afa2] spapr: Render full FDT on
ibm,client-architecture-support, reverting this commit boot the guest
properly.
git bisect start
# good: [9e06029aea3b2eca1d5261352e695edc1e7d7b8b] Update version for v4.1.0
release
git bisect good 9e06029aea3b2eca1d5261352e695edc1e7d7b8b
# bad: [98b2e3c9ab3abfe476a2b02f8f51813edb90e72d] Merge remote-tracking
branch 'remotes/stefanha/tags/block-pull-request' into staging
git bisect bad 98b2e3c9ab3abfe476a2b02f8f51813edb90e72d
# good: [56e6250ede81b4e4b4ddb623874d6c3cdad4a96d] target/arm: Convert T16,
nop hints
git bisect good 56e6250ede81b4e4b4ddb623874d6c3cdad4a96d
# good: [5d69cbdfdd5cd6dadc9f0c986899844a0e4de703] tests/tcg: target/s390x:
Test MVC
git bisect good 5d69cbdfdd5cd6dadc9f0c986899844a0e4de703
# good: [88112488cf228df8b7588c8aa38e16ecd0dff48e] qapi: Make check_type()'s
array case a bit more obvious
git bisect good 88112488cf228df8b7588c8aa38e16ecd0dff48e
# good: [972bd57689f1e11311d86b290134ea2ed9c7c11e] ppc/kvm: Skip writing
DPDES back when in run time state
git bisect good 972bd57689f1e11311d86b290134ea2ed9c7c11e
# bad: [1aba8716c8335e88b8c358002a6e1ac89f7dd258] ppc/pnv: Remove the
XICSFabric Interface from the POWER9 machine
git bisect bad 1aba8716c8335e88b8c358002a6e1ac89f7dd258
# bad: [00ed3da9b5c2e66e796a172df3e19545462b9c90] xics: Minor fixes for
XICSFabric interface
git bisect bad 00ed3da9b5c2e66e796a172df3e19545462b9c90
# good: [33432d7737b53c92791f90ece5dbe3b7bb1c79f5] target/ppc: introduce
set_dfp{64,128}() helper functions
git bisect good 33432d7737b53c92791f90ece5dbe3b7bb1c79f5
# good: [f6d4c423a222f02bfa84a49c3d306d7341ec9bab] target/ppc: remove
unnecessary if() around calls to set_dfp{64,128}() in DFP macros
git bisect good f6d4c423a222f02bfa84a49c3d306d7341ec9bab
# bad: [e68cd0cb5cf49d334abe17231a1d2c28b846afa2] spapr: Render full FDT on
ibm,client-architecture-support
git bisect bad e68cd0cb5cf49d334abe17231a1d2c28b846afa2
# good: [c4ec08ab70bab90685d1443d6da47293e3aa312a] spapr-pci: Stop providing
assigned-addresses
git bisect good c4ec08ab70bab90685d1443d6da47293e3aa312a
# first bad commit: [e68cd0cb5cf49d334abe17231a1d2c28b846afa2] spapr: Render
full FDT on ibm,client-architecture-support
attached vmxml.
qemu commandline:
/home/sath/qemu/ppc64-softmmu/qemu-system-ppc64 -name
guest=vm1,debug-threads=on -S -object
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-19-vm1/master-key.aes
-machine pseries-4.2,accel=kvm,usb=off,dump-guest-core=off -m 81920
-overcommit mem-lock=off -smp 512,sockets=1,cores=128,threads=4 -uuid
fd4a5d54-0216-490e-82d2-1d4e89683b3d -display none -no-user-config -nodefaults
-chardev socket,id=charmonitor,fd=24,server,nowait -mon
chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot
strict=on -device
[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1847793 Title: qemu 4.1.0 - Corrupt guest filesystem after new vm install Status in QEMU: Incomplete Bug description: When I install a new vm with qemu 4.1.0 all the guest filesystems are corrupt. The first boot from the install dvd iso is ok and the installer work fine. But the guest system hangs after the installer finishes and I reboot the guest. I can see the grub boot menue but the system cannot load the initramfs. Testet with: - RedHat Enterprise Linux 7.5, 7.6 and 7.7 (RedHat uses xfs for the /boot and / partition) Guided install with the graphical installer, no lvm selected. - Debian Stable/Buster (Debian uses ext4 for / and /home partition) Guidet install with the graphical installer and default options. Used commandline to create the vm disk image: qemu-img create -f qcow2 /volumes/disk2-part2/vmdisks/vmtest10-1.qcow2 20G Used qemu commandline for vm installation: #!/bin/sh # vmtest10 Installation # /usr/bin/qemu-system-x86_64 -cpu SandyBridge-IBRS \ -soundhw hda \ -M q35 \ -k de \ -vga qxl \ -machine accel=kvm \ -m 4096 \ -display gtk \ -drive file=/volumes/disk2-part2/images/debian-10.0.0-amd64-DVD-1.iso,if=ide,media=cdrom \ -drive file=/volumes/disk2-part2/images/vmtest10-1.qcow2,if=virtio,media=disk,cache=writeback \ -boot once=d,menu=off \ -device virtio-net-pci,mac=52:54:00:2c:02:6c,netdev=vlan0 \ -netdev bridge,br=br0,id=vlan0 \ -rtc base=localtime \ -name "vmtest10" \ -usb -device usb-tablet \ -spice disable-ticketing \ -device virtio-serial-pci \ -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 \ -chardev spicevmc,id=spicechannel0,name=vdagent $* Host OS: Archlinux (last updated at 10.10.2019) Linux testing 5.3.5-arch1-1-ARCH #1 SMP PREEMPT Mon Oct 7 19:03:08 UTC 2019 x86_64 GNU/Linux No libvirt in use. With qemu 4.0.0 it works fine without any errors. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1847793/+subscriptions
[Bug 1847525] Re: qemu-system-i386 eats a lot of cpu after just few hours, with sdl, gl=on
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1847525 Title: qemu-system-i386 eats a lot of cpu after just few hours, with sdl,gl=on Status in QEMU: Incomplete Bug description: I already send this email to qemu-disc...@nongnu.org , but I can't see it arriving in archives, so here is copy. Hello, all! I use qemu-system-i386/qemu-system_x86_64 for rebuilding Slax-like live cd/dvd. Usually guests (with various self-compiled kernels and X stack with kde3 on top of them) boot up normally, but if I left them to run in GUI mode for few hours - qemu process on host started to eat more and more cpu for itself - more notiecable if I set host cpu to lowest possible frequency via trayfreq applet (1400Mhz in my case). Boot line a bit complicated, but I really prefer to have sound and usb inside VM. qemu-system-i386 -cdrom /dev/shm/CDROM-4.4.194_5.iso -m 1.9G -enable-kvm -soundhw es1370 -smp 2 -display sdl,gl=on -usb -cpu host -rtc clock=vm rtc clock=vm was taken from https://bugs.launchpad.net/qemu/+bug/1174654 but apparently not helping. After just 3 hours of uptime (copied line from 'top' on host) 31943 guest 20 0 2412m 791m 38m R 51 6.7 66:36.51 qemu- system-i38 I use Xorg 1.19.7 on host, with mesa git/nouveau as GL driver. But my card has not very big amount of VRAM - only 384Mb. May be this limitation is playing some role .. but 'end-user' result was after 1-2 day of guest uptime I run into completely frozen guest (may be when qemu was hitting 100 one core usage on host some internal timer just made guest kernel too upset/froze? I was sleeping or doing other things on host for all this time, with VM just supposedly running at another virtual desktop - in KDE3 + built-in compositor ) I wonder if more mainstream desktop users (on GNOME, Xfce, etc) and/or users of other distros (I use self-re-compiled Slackware) actually can see same problem? qemu-system-i386 --version QEMU emulator version 4.1.50 (v4.1.0-1188-gc6f5012ba5-dirty) but I saw same behavior for quite some time .. just never reported it in hope it will go away. cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-4300 Quad-Core Processor stepping: 0 microcode : 0x6000852 cpu MHz : 1399.977 cache size : 2048 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 2 apicid : 16 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate ssbd vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bugs: fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass bogomips: 7600.06 TLB size: 1536 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro [and 3x more of the same, for 3 remaining cores] Gcc is Slackware 14.2's gcc 5.5.0, but I saw this with 4.9.2 too. This might be 32-bit host problem. But may be just no-one tried to run qemu with GUI guest for literaly days? Host kernel is uname -a Linux slax 5.1.12-x64 #1 SMP PREEMPT Wed Jun 19 12:31:05 MSK 2019 x86_64 AMD FX(tm)-4300 Quad-Core Processor AuthenticAMD GNU/Linux I was trying newish 5.3.2 but my compilation was not as stable as this one (I tend to change few things, like max cpu count, preemption mode, numa support for more distribution-like, yet most stable and performant for me kernel) Kernel world is moving fast, so I'll try to recompi
[Bug 1846392] Re: VCPU shutdown request with HAX
The QEMU project is currently considering to move its bug tracking to
another system. For this we need to know which bugs are still valid
and which could be closed already. Thus we are setting older bugs to
"Incomplete" now.
If you still think this bug report here is valid, then please switch
the state back to "New" within the next 60 days, otherwise this report
will be marked as "Expired". Or please mark it as "Fix Released" if
the problem has been solved with a newer version of QEMU already.
Thank you and sorry for the inconvenience.
** 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/1846392
Title:
VCPU shutdown request with HAX
Status in QEMU:
Incomplete
Bug description:
In most scenarios when turning on HAX, QEMU will exit, printing "VCPU
shutdown request" to the console.
This is on Windows 8.1 with Intel HAXM 7.5.2.
QEMU's -version prints v4.1.0-11789-g013a2ecf4f-dirty .
I've used an installer from qemu.weilnetz.de.
The host CPU is an IvyBridge i5 (mobile).
Some miscellaneous notes (you can skip them first):
Win10-1709-PE_Custom.iso is a custom WinPE image I had meant to test using
QEMU. It is likely broken and doesn't boot at all.
[Stuck, etc.]: I had given that image almost 2h during which the circle of
dots continued to spin. I don't know if it or QEMU did anything of interest at
all during that period, but this might indicate long-term stability, sort of.
Win10_1709_German_x32.iso: Stock Win10 1709 32bit ISO I got off a German tech
website. I've waited for the install screen to appear.
TinyCore_10-1.iso: TinyCore by Core Project. A 18MB graphical Linux
distribution, pretty barren by default. I've generally opened Apps there, the
package manager, then shut it down again.
On the one marked [Fx stable], I've gotten Firefox 60.8.0 ESR and visited a
couple of websites. (I don't know of any available program that would try to
execute exotic CPU instructions in weird combinations to do a proper test.)
Q64 is .\qemu-system-x86_64.exe , substituted for readability (shorter lines).
Invocations that QEMU seemed to handle well (without the headline error):
Q64 -machine q35 -accel hax
Q64 -machine q35 -cdrom \!S\Win10-1709-PE_Custom.iso
Q64 -machine q35 -cdrom \!S\Win10-1709-PE_Custom.iso -m 4096 [Stuck, etc.]
Q64 -machine q35 -cdrom \!S\Win10_1709_German_x32.iso -m 1920
Q64 -machine q35 -cdrom \!S\Win10_1709_German_x32.iso -cpu max -m 256 [1]
Q64 -machine q35 -cdrom \!S\Win10_1709_German_x32.iso -cpu max -m 512
Q64 -cdrom \!S\TinyCore_10-1.iso -m 512
Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -cpu max -serial
file:\!S\QEMU_TCL_BUG.log [2]
Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax [Fx stable, s.a.]
Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu Skylake-Client-IBRS
Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu Icelake-Client-v1
Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu Cascadelake-Server-v2
Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu Broadwell-v4
Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu IvyBridge-IBRS
Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu coreduo
Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu pentium
Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu base [3]
Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -cpu base [4]
Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -cpu pentium
Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu Icelake-Client-v1 [5]
Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu Broadwell-v4 [5]
Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu IvyBridge-v1 [5]
Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu coreduo
Then, those that made it print "VCPU shutdown request" repeatedly and quit,
immediately or after a couple of seconds at most, except where noted. I put an
indication of the number of messages into curly braces.
Q64 -machine q35,accel=hax -cpu max {many}
Q64 -machine q35,accel=hax -cdrom \!S\Win10-1709-PE_Custom.iso
Q64 -machine q35 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -accel hax
{very many}
Q64 -machine q35 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -accel hax -cpu
max {very many}
Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -accel hax {just two}
Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu max {a couple}
Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu Icelake-Client-v1 -accel
hax {two}
Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu IvyBridge-v1 -accel hax
{two}
Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu pentium -accel hax
{three}
Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu coreduo -accel hax {a
few}
(I have rewritten a couple of commandlines to make them more uniform
(changing the placement of parameters and using '-accel hax' instead
of '-
Re: [PATCH 2/3] Acceptance Tests: move definition of distro checksums to the framework
Hi Cleber,
On 4/15/21 12:14 AM, Cleber Rosa wrote:
> Instead of having, by default, the checksum in the tests, and the
> definition of tests in the framework, let's keep them together.
>
> A central definition for distributions is available, and it should
> allow other known distros to be added more easily.
>
> No behavior change is expected here, and tests can still define
> a distro_checksum value if for some reason they want to override
> the known distribution information.
>
> Signed-off-by: Cleber Rosa
> ---
> tests/acceptance/avocado_qemu/__init__.py | 34 +--
> tests/acceptance/boot_linux.py| 8 --
> 2 files changed, 32 insertions(+), 10 deletions(-)
>
> diff --git a/tests/acceptance/avocado_qemu/__init__.py
> b/tests/acceptance/avocado_qemu/__init__.py
> index aae1e5bbc9..97093614d9 100644
> --- a/tests/acceptance/avocado_qemu/__init__.py
> +++ b/tests/acceptance/avocado_qemu/__init__.py
> @@ -299,6 +299,30 @@ def ssh_command(self, command):
> return stdout_lines, stderr_lines
>
>
> +#: A collection of known distros and their respective image checksum
> +KNOWN_DISTROS = {
> +'fedora': {
> +'31': {
> +'x86_64':
> +{'checksum':
> 'e3c1b309d9203604922d6e255c2c5d098a309c2d46215d8fc026954f3c5c27a0'},
> +'aarch64':
> +{'checksum':
> '1e18d9c0cf734940c4b5d5ec592facaed2af0ad0329383d5639c997fdf16fe49'},
> +'ppc64':
> +{'checksum':
> '7c3528b85a3df4b2306e892199a9e1e43f991c506f2cc390dc4efa2026ad2f58'},
> +'s390x':
> +{'checksum':
> '4caaab5a434fd4d1079149a072fdc7891e354f834d355069ca982fdcaf5a122d'},
> +}
> +}
> +}
assuming we may put other data like kernel params and maybe pxeboot URL,
this may grow rapidly, Maybe we should put that in a different file?
> +
> +
> +def get_known_distro_checksum(distro, distro_version, arch):
> +try:
> +return
> KNOWN_DISTROS.get(distro).get(distro_version).get(arch).get('checksum')
> +except AttributeError:
> +return None
> +
> +
> class LinuxTest(Test, LinuxSSHMixIn):
> """Facilitates having a cloud-image Linux based available.
>
> @@ -348,14 +372,20 @@ def download_boot(self):
> vmimage.QEMU_IMG = qemu_img
>
> self.log.info('Downloading/preparing boot image')
> +distro = 'fedora'
> +distro_version = '31'
> +known_distro_checksum = get_known_distro_checksum(distro,
> + distro_version,
> + self.arch)
> +distro_checksum = self.distro_checksum or known_distro_checksum
> # Fedora 31 only provides ppc64le images
> image_arch = self.arch
> if image_arch == 'ppc64':
> image_arch = 'ppc64le'
> try:
> boot = vmimage.get(
> -'fedora', arch=image_arch, version='31',
> -checksum=self.distro_checksum,
> +distro, arch=image_arch, version=distro_version,
> +checksum=distro_checksum,
> algorithm='sha256',
> cache_dir=self.cache_dirs[0],
> snapshot_dir=self.workdir)
> diff --git a/tests/acceptance/boot_linux.py b/tests/acceptance/boot_linux.py
> index c7bc3a589e..9e618c6daa 100644
> --- a/tests/acceptance/boot_linux.py
> +++ b/tests/acceptance/boot_linux.py
> @@ -20,8 +20,6 @@ class BootLinuxX8664(LinuxTest):
> :avocado: tags=arch:x86_64
> """
>
> -distro_checksum =
> 'e3c1b309d9203604922d6e255c2c5d098a309c2d46215d8fc026954f3c5c27a0'
> -
> def test_pc_i440fx_tcg(self):
> """
> :avocado: tags=machine:pc
> @@ -66,8 +64,6 @@ class BootLinuxAarch64(LinuxTest):
> :avocado: tags=machine:gic-version=2
> """
>
> -distro_checksum =
> '1e18d9c0cf734940c4b5d5ec592facaed2af0ad0329383d5639c997fdf16fe49'
> -
> def add_common_args(self):
> self.vm.add_args('-bios',
> os.path.join(BUILD_DIR, 'pc-bios',
> @@ -119,8 +115,6 @@ class BootLinuxPPC64(LinuxTest):
> :avocado: tags=arch:ppc64
> """
>
> -distro_checksum =
> '7c3528b85a3df4b2306e892199a9e1e43f991c506f2cc390dc4efa2026ad2f58'
> -
> def test_pseries_tcg(self):
> """
> :avocado: tags=machine:pseries
> @@ -136,8 +130,6 @@ class BootLinuxS390X(LinuxTest):
> :avocado: tags=arch:s390x
> """
>
> -distro_checksum =
> '4caaab5a434fd4d1079149a072fdc7891e354f834d355069ca982fdcaf5a122d'
> -
> @skipIf(os.getenv('GITLAB_CI'), 'Running on GitLab')
> def test_s390_ccw_virtio_tcg(self):
> """
>
Thanks
Eric
Re: [PATCH v3 2/3] vhost-user-blk: perform immediate cleanup if disconnect on initialization
On 21.04.2021 22:59, Michael S. Tsirkin wrote:
On Wed, Apr 21, 2021 at 07:13:24PM +0300, Denis Plotnikov wrote:
On 21.04.2021 18:24, Kevin Wolf wrote:
Am 25.03.2021 um 16:12 hat Denis Plotnikov geschrieben:
Commit 4bcad76f4c39 ("vhost-user-blk: delay vhost_user_blk_disconnect")
introduced postponing vhost_dev cleanup aiming to eliminate qemu aborts
because of connection problems with vhost-blk daemon.
However, it introdues a new problem. Now, any communication errors
during execution of vhost_dev_init() called by vhost_user_blk_device_realize()
lead to qemu abort on assert in vhost_dev_get_config().
This happens because vhost_user_blk_disconnect() is postponed but
it should have dropped s->connected flag by the time
vhost_user_blk_device_realize() performs a new connection opening.
On the connection opening, vhost_dev initialization in
vhost_user_blk_connect() relies on s->connection flag and
if it's not dropped, it skips vhost_dev initialization and returns
with success. Then, vhost_user_blk_device_realize()'s execution flow
goes to vhost_dev_get_config() where it's aborted on the assert.
To fix the problem this patch adds immediate cleanup on device
initialization(in vhost_user_blk_device_realize()) using different
event handlers for initialization and operation introduced in the
previous patch.
On initialization (in vhost_user_blk_device_realize()) we fully
control the initialization process. At that point, nobody can use the
device since it isn't initialized and we don't need to postpone any
cleanups, so we can do cleaup right away when there is a communication
problem with the vhost-blk daemon.
On operation we leave it as is, since the disconnect may happen when
the device is in use, so the device users may want to use vhost_dev's data
to do rollback before vhost_dev is re-initialized (e.g. in vhost_dev_set_log()).
Signed-off-by: Denis Plotnikov
Reviewed-by: Raphael Norwitz
I think there is something wrong with this patch.
I'm debugging an error case, specifically num-queues being larger in
QEMU that in the vhost-user-blk export. Before this patch, it has just
an unfriendly error message:
qemu-system-x86_64: -device
vhost-user-blk-pci,chardev=vhost1,id=blk1,iommu_platform=off,disable-legacy=on,num-queues=4:
Unexpected end-of-file before all data were read
qemu-system-x86_64: -device
vhost-user-blk-pci,chardev=vhost1,id=blk1,iommu_platform=off,disable-legacy=on,num-queues=4:
Failed to read msg header. Read 0 instead of 12. Original request 24.
qemu-system-x86_64: -device
vhost-user-blk-pci,chardev=vhost1,id=blk1,iommu_platform=off,disable-legacy=on,num-queues=4:
vhost-user-blk: get block config failed
qemu-system-x86_64: Failed to set msg fds.
qemu-system-x86_64: vhost VQ 0 ring restore failed: -1: Resource temporarily
unavailable (11)
After the patch, it crashes:
#0 0x55d0a4bd in vhost_user_read_cb (source=0x568f4690,
condition=(G_IO_IN | G_IO_HUP), opaque=0x7fffcbf0) at
../hw/virtio/vhost-user.c:313
#1 0x55d950d3 in qio_channel_fd_source_dispatch (source=0x57c3f750,
callback=0x55d0a478 , user_data=0x7fffcbf0) at
../io/channel-watch.c:84
#2 0x77b32a9f in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#3 0x77b84a98 in g_main_context_iterate.constprop () at
/lib64/libglib-2.0.so.0
#4 0x77b32163 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#5 0x55d0a724 in vhost_user_read (dev=0x57bc62f8,
msg=0x7fffcc50) at ../hw/virtio/vhost-user.c:402
#6 0x55d0ee6b in vhost_user_get_config (dev=0x57bc62f8,
config=0x57bc62ac "", config_len=60) at ../hw/virtio/vhost-user.c:2133
#7 0x55d56d46 in vhost_dev_get_config (hdev=0x57bc62f8,
config=0x57bc62ac "", config_len=60) at ../hw/virtio/vhost.c:1566
#8 0x55cdd150 in vhost_user_blk_device_realize (dev=0x57bc60b0,
errp=0x7fffcf90) at ../hw/block/vhost-user-blk.c:510
#9 0x55d08f6d in virtio_device_realize (dev=0x57bc60b0,
errp=0x7fffcff0) at ../hw/virtio/virtio.c:3660
The problem is that vhost_user_read_cb() still accesses dev->opaque even
though the device has been cleaned up meanwhile when the connection was
closed (the vhost_user_blk_disconnect() added by this patch), so it's
NULL now. This problem was actually mentioned in the comment that is
removed by this patch.
I tried to fix this by making vhost_user_read() cope with the fact that
the device might have been cleaned up meanwhile, but then I'm running
into the next set of problems.
The first is that retrying is pointless, the error condition is in the
configuration, it will never change.
The other is that after many repetitions of the same error message, I
got a crash where the device is cleaned up a second time in
vhost_dev_init() and the virtqueues are already NULL.
So it seems to me that erroring out during the initialisation phase
makes a lot more sense than retrying.
Kevin
But without the patch there will be anothe
Re: [PATCH v3 0/8] qapi: static typing conversion, pt4
John Snow writes: > Hi, this series adds static type hints to the QAPI module. > This is part four, and focuses on error.py. > > Part 4: https://gitlab.com/jsnow/qemu/-/tree/python-qapi-cleanup-pt4 > CI: https://gitlab.com/jsnow/qemu/-/pipelines/290152364 > > Requirements: > - Python 3.6+ > - mypy >= 0.770 > - pylint >= 2.6.0 (2.7.0+ when using Python 3.9+) > > Every commit should pass with: > - `isort -c qapi/` > - `flake8 qapi/` > - `pylint --rcfile=qapi/pylintrc qapi/` > - `mypy --config-file=qapi/mypy.ini qapi/` I doubt PATCH 1 is worth the trouble without an actual concrete location-less error. However, arguing about it some more would also not worth the trouble, so: Reviewed-by: Markus Armbruster and queued. Thanks!
[PATCH] target/mips: Remove spurious LOG_UNIMP of MTHC0 opcode
When running with '-d unimp' all MTHC0 opcode executed
are logged as unimplemented... Add the proper 'return'
statement missed from commit 5204ea79ea7.
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/translate.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/mips/translate.c b/target/mips/translate.c
index 71fa5ec1973..269bdba400f 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -5945,6 +5945,7 @@ static void gen_mthc0(DisasContext *ctx, TCGv arg, int
reg, int sel)
goto cp0_unimplemented;
}
trace_mips_translate_c0("mthc0", register_name, reg, sel);
+return;
cp0_unimplemented:
qemu_log_mask(LOG_UNIMP, "mthc0 %s (reg %d sel %d)\n",
--
2.26.3
[Bug 1754656] Re: Please solve graceful (ACPI) poweroff issue, using signals, most importantly SIGTERM
** Changed in: qemu Status: Incomplete => New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1754656 Title: Please solve graceful (ACPI) poweroff issue, using signals, most importantly SIGTERM Status in QEMU: New Bug description: Version: QEMU emulator version 2.11.1 Introduction: This is call for action to get attention of somebody in QEMU project/organization, who is capable of actually doing something about this pressing issue. This might be TLDR for some, but that's only because of the complexity of the issue. Please read this with open mind. Problem: As QEMU users, we need (it is a requirement) to have some mechanism in place, to somehow convert simple POSIX signal sent form host, into graceful ACPI shutdown of the guest. This signal, due various historical reasons and daemon design, must be SIGTERM foremost. Status quo: After wading through mailing lists and bug tracker I concluded that this is "political" problem and I am in search of somebody, a "politician" within QEMU project, who will help us reach conclusion to this problem. First I will present analysis of the situation, and then propose some suggestions for solutions. Even then, any of these proposals might be, potentially, seen as problematic in eyes of QEMU maintainers, developers, dictators, long term users or their dogs. That's why we need somebody willing, "higher up the chain" or whatever, to orchestrate discussion so that we can actually reach consensus in the matter, solution that is acceptable to **everyone**. Analysis: Each QEMU emulated virtual machine (vm), running in the host system, is represented by single qemu-* process (followed by several threads). Thus for all intents and purposes, any such instantiated vm, must be seen as it's own, separate, daemon. I repeat running qemu-* vm **is a daemon**. QEMU provides incredible IO redirection capabilities, so we don't need to get into issues of logging, console and monitor redirections and such, as this is already a (perfectly) solved problem. What we cannot currently do, at least easily, reliably and simply, is to shutdown guest gracefully from "outside". That is not a problem for those of us, who use some kind of higher level orchestrator (I think one of them is virsh, but this is not important in this matter) that takes care of this by communicating with QEMU directly (I guess this is done by sending commands to internal monitor by pipe (or socket) held open by mentioned orchestrator). However it is a problem for those of us, who run qemu-* processes bare or supervised. Let's say I, as administrator, want to implement vm instance as supervised service. I can use any supervisor for that, systemd even. Let us not get into into supervisor wars. At basic level almost all supervisors are similar. Supervisor usually is yet another process, that "leads" the qemu-* one. In case of systemd it is PID1, but in case of other supervision schemes, like daemontools, runit, s6 or nosh, it is separate '*supervise' process instead. When such supervisor is tearing down the service, "leading"/supervising, parent will send SIGTERM to it's child qemu-* process. This behaviour is almost universal among all supervisors. This due the fact, that it is customary for daemons to cease all operations and exit cleanly when receiving SGITERM signal. If daemon child fails to exit within configurable timeframe, supervisor deals with it by the means of SIGKILL. As such, one would expect, similarly, for qemu-* process to send ACPI shutdown event to guest internally (roughly equivalent to 'system_powerdown' monitor command) on SIGTERM reception. But this is not what happens! Instead, qemu-* just flushes pending IO and kills the guest instantly. Then, on next vm "boot", guest detects this as power failure event, and performs fsck checks and other things, it is supposed to do in case of power failure. We are not mentioning possible data loss that might have happened due to this behavior, either. Some supervisors (like systemd for example) might provide feature to change "termiante operations" signal to something else like SIGTERM, but that is not universal supervisor feature by any means. Default action for any proper daemon is to cleanly terminate on SIGTERM. That is why we need ability to somehow instruct QEMU to **always** perform graceful ACPI shutdown on SIGTERM. Potential reply to this bug saying that one should send 'system_powerdown' over monitor connection won't fly! As it is not always possible (nor required) to hook into supervisor's signal processing (main reason being intentional supervisor simplicity in search of extreme reliability, and de facto standardized behavior of daemons to exit cleanly on SIGTE
[Bug 1721788] Re: Failed to get shared "write" lock with 'qemu-img info'
** Description changed: When running 'qemu-img info test.qcow2' while test.qcow2 is currently used by a Qemu process, I get the error qemu-img: Could not open 'test.qcow2': Failed to get shared "write" lock. - - Why does displaying information about a disk image need a write lock for the file? + Why does displaying information about a disk image need a write lock for + the file? Steps to reproduce: qemu-img create -f qcow2 test.qcow2 10M qemu-system-x86_64 -nographic -drive file=test.qcow2 qemu-img info test.qcow2 - The above was tested with Qemu version 2.10.0 + The above was tested with Qemu version 2.10.0. Edit: Same behaviour with + version 5.2.0. ** Changed in: qemu Status: Incomplete => New ** Description changed: When running 'qemu-img info test.qcow2' while test.qcow2 is currently used by a Qemu process, I get the error qemu-img: Could not open 'test.qcow2': Failed to get shared "write" lock. Why does displaying information about a disk image need a write lock for the file? Steps to reproduce: qemu-img create -f qcow2 test.qcow2 10M qemu-system-x86_64 -nographic -drive file=test.qcow2 qemu-img info test.qcow2 - The above was tested with Qemu version 2.10.0. Edit: Same behaviour with - version 5.2.0. + The above was tested with Qemu version 2.10.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/1721788 Title: Failed to get shared "write" lock with 'qemu-img info' Status in QEMU: New Bug description: When running 'qemu-img info test.qcow2' while test.qcow2 is currently used by a Qemu process, I get the error qemu-img: Could not open 'test.qcow2': Failed to get shared "write" lock. Why does displaying information about a disk image need a write lock for the file? Steps to reproduce: qemu-img create -f qcow2 test.qcow2 10M qemu-system-x86_64 -nographic -drive file=test.qcow2 qemu-img info test.qcow2 The above was tested with Qemu version 2.10.0. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1721788/+subscriptions
[PATCH] Fix typo in CFI build documentation
From: serge-sans-paille Signed-off-by: Serge Guelton Reviewed-by: Philippe Mathieu-Daudé --- docs/devel/control-flow-integrity.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/devel/control-flow-integrity.rst b/docs/devel/control-flow-integrity.rst index d89d707..e6b73a4 100644 --- a/docs/devel/control-flow-integrity.rst +++ b/docs/devel/control-flow-integrity.rst @@ -39,7 +39,7 @@ later). Given the use of LTO, a version of AR that supports LLVM IR is required. The easies way of doing this is by selecting the AR provided by LLVM:: - AR=llvm-ar-9 CC=clang-9 CXX=lang++-9 /path/to/configure --enable-cfi + AR=llvm-ar-9 CC=clang-9 CXX=clang++-9 /path/to/configure --enable-cfi CFI is enabled on every binary produced. @@ -131,7 +131,7 @@ lld with version 11+. In other words, to compile with fuzzing and CFI, clang 11+ is required, and lld needs to be used as a linker:: - AR=llvm-ar-11 CC=clang-11 CXX=lang++-11 /path/to/configure --enable-cfi \ + AR=llvm-ar-11 CC=clang-11 CXX=clang++-11 /path/to/configure --enable-cfi \ -enable-fuzzing --extra-ldflags="-fuse-ld=lld" and then, compile the fuzzers as usual. -- 1.8.3.1
[Trivial] docs: More precisely describe memory-backend-*::id's user
'id' of memory-backend-{file,ram} is not only for '-numa''s reference, but
also other parameters like '-device nvdimm'.
More clearly call out this to avoid misinterpretation.
Signed-off-by: Robert Hoo
---
qemu-options.hx | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index fd21002..635dc8a 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -4508,11 +4508,11 @@ SRST
the guest RAM with huge pages.
The ``id`` parameter is a unique ID that will be used to
-reference this memory region when configuring the ``-numa``
-argument.
+reference this memory region in other parameters, e.g. ``-numa``,
+``-device nvdimm``, etc.
The ``size`` option provides the size of the memory region, and
-accepts common suffixes, eg ``500M``.
+accepts common suffixes, e.g. ``500M``.
The ``mem-path`` provides the path to either a shared memory or
huge page filesystem mount.
--
1.8.3.1
Re: [PATCH v3 02/33] block/nbd: fix how state is cleared on nbd_open() failure paths
On Thu, Apr 22, 2021 at 01:27:22AM +0300, Vladimir Sementsov-Ogievskiy wrote:
> 21.04.2021 17:00, Roman Kagan wrote:
> > On Fri, Apr 16, 2021 at 11:08:40AM +0300, Vladimir Sementsov-Ogievskiy
> > wrote:
> > > @@ -2305,20 +2301,23 @@ static int nbd_open(BlockDriverState *bs, QDict
> > > *options, int flags,
> > > return -EEXIST;
> > > }
> > > +ret = nbd_process_options(bs, options, errp);
> > > +if (ret < 0) {
> > > +goto fail;
> > > +}
> > > +
> > > /*
> > >* establish TCP connection, return error if it fails
> > >* TODO: Configurable retry-until-timeout behaviour.
> > >*/
> > > if (nbd_establish_connection(bs, s->saddr, errp) < 0) {
> > > -yank_unregister_instance(BLOCKDEV_YANK_INSTANCE(bs->node_name));
> > > -return -ECONNREFUSED;
> > > +ret = -ECONNREFUSED;
> > > +goto fail;
> > > }
> > > ret = nbd_client_handshake(bs, errp);
> > Not that this was introduced by this patch, but once you're at it:
> > AFAICT nbd_client_handshake() calls yank_unregister_instance() on some
> > error path(s); I assume this needs to go too, otherwise it's called
> > twice (and asserts).
> >
> > Roman.
> >
>
> No, nbd_client_handshake() only calls yank_unregister_function(), not
> instance.
Indeed. Sorry for confusion.
Reviewed-by: Roman Kagan
[Bug 1848901] Re: kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device (28)
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1848901 Title: kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device (28) Status in QEMU: Incomplete Bug description: => QEMU process has stopped, return code: -6 Start QEMU with /usr/bin/qemu-system-x86_64 -name CiscoASAv9.8.1-1 -m 2048M -smp cpus=1 -enable-kvm -machine smm=off -boot order=c -drive 'file=/home/deemon/GNS3/projects/ASAv my ass/project-files/qemu /7725cdea-5e66-4777-b4dd- c3905f258394/hda_disk.qcow2,if=virtio,index=0,media=disk,id=drive0' -uuid 7725cdea-5e66-4777-b4dd-c3905f258394 -serial telnet:127.0.0.1:5000,server,nowait -monitor tcp:127.0.0.1:44629,server,nowait -net none -device e1000,mac=0c:7a:1d:83:94:00,netdev=gns3-0 -netdev socket,id=gns3-0,udp=127.0.0.1:10001,localaddr=127.0.0.1:1 -device e1000,mac=0c:7a:1d:83:94:01,netdev=gns3-1 -netdev socket,id=gns3-1,udp=127.0.0.1:10003,localaddr=127.0.0.1:10002 -device e1000,mac=0c:7a:1d:83:94:02,netdev=gns3-2 -netdev socket,id=gns3-2,udp=127.0.0.1:10005,localaddr=127.0.0.1:10004 -device e1000,mac=0c:7a:1d:83:94:03,netdev=gns3-3 -netdev socket,id=gns3-3,udp=127.0.0.1:10007,localaddr=127.0.0.1:10006 -device e1000,mac=0c:7a:1d:83:94:04,netdev=gns3-4 -netdev socket,id=gns3-4,udp=127.0.0.1:10009,localaddr=127.0.0.1:10008 -device e1000,mac=0c:7a:1d:83:94:05,netdev=gns3-5 -netdev socket,id=gns3-5,udp=127.0.0.1:10011,localaddr=127.0.0.1:10010 -device e1000,mac=0c:7a:1d:83:94:06,netdev=gns3-6 -netdev socket,id=gns3-6,udp=127.0.0.1:10013,localaddr=127.0.0.1:10012 -device e1000,mac=0c:7a:1d:83:94:07,netdev=gns3-7 -netdev socket,id=gns3-7,udp=127.0.0.1:10015,localaddr=127.0.0.1:10014 -nographic Execution log: kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device (28) and then it just closes... [deemon@Zen ~]$ coredumpctl info 8638 PID: 8638 (qemu-system-x86) UID: 1000 (deemon) GID: 1000 (deemon) Signal: 6 (ABRT) Timestamp: Sun 2019-10-20 04:27:29 EEST (5min ago) Command Line: /usr/bin/qemu-system-x86_64 -name CiscoASAv9.8.1-1 -m 2048M -smp cpus=1 -enable-kvm -machine smm=off -boot order=c -drive file=/home/deemon/GNS3/projects/ASAv my ass/project-files/qemu> Executable: /usr/bin/qemu-system-x86_64 Control Group: /user.slice/user-1000.slice/session-2.scope Unit: session-2.scope Slice: user-1000.slice Session: 2 Owner UID: 1000 (deemon) Boot ID: cd30f69a8d194359a31889dc7b6b026c Machine ID: d0a2d74a5cd9430797d902f5237c448d Hostname: Zen Storage: /var/lib/systemd/coredump/core.qemu-system-x86.1000.cd30f69a8d194359a31889dc7b6b026c.8638.157153484900.lz4 (truncated) Message: Process 8638 (qemu-system-x86) of user 1000 dumped core. Stack trace of thread 8642: #0 0x7f1a33609f25 n/a (n/a) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1848901/+subscriptions
[Bug 1849894] Re: hw/scsi/scsi-disk.c line 2554 allocation overflow
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1849894 Title: hw/scsi/scsi-disk.c line 2554 allocation overflow Status in QEMU: Incomplete Bug description: When compiling qemu from git master (at commit 03bf012e523ecdf047ac56b2057950247256064d ) on Linux amd64, with gcc-9 9.2.1 , and using `-march=native -flto`, during linking of most target binaries, compiler does detect an issue with allocation in scsi_disk_new_request_dump and aborts compilation. make[1]: Entering directory '/home/user/qemu/slirp' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/user/qemu/slirp' nm: stats64.o: no symbols LINKaarch64-softmmu/qemu-system-aarch64 In function ‘scsi_disk_new_request_dump’, inlined from ‘scsi_new_request’ at hw/scsi/scsi-disk.c:2580:9, inlined from ‘scsi_new_request’ at hw/scsi/scsi-disk.c:2564:21: hw/scsi/scsi-disk.c:2554:19: error: argument 1 value ‘18446744073709551612’ exceeds maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=] hw/scsi/scsi-disk.c: In function ‘scsi_new_request’: /usr/include/glib-2.0/glib/gmem.h:78:10: note: in a call to allocation function ‘g_malloc’ declared here 78 | gpointer g_malloc (gsize n_bytes) G_GNUC_MALLOC G_GNUC_ALLOC_SIZE(1); | ^ lto1: all warnings being treated as errors lto-wrapper: fatal error: c++ returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status same happens for most other targets: alpha-softmmu/qemu-system-alpha arm-softmmu/qemu-system-arm hppa-softmmu/qemu-system-hppa i386-softmmu /qemu-system-i386 lm32-softmmu/qemu-system-lm32 mips-softmmu/qemu- system-mips mips64-softmmu/qemu-system-mips64 mips64el-softmmu/qemu- system-mips64el mipsel-softmmu/qemu-system-mipsel ppc-softmmu/qemu- system-ppc ppc64-softmmu/qemu-system-ppc64 riscv32-softmmu/qemu- system-riscv32 riscv64-softmmu/qemu-system-riscv64 s390x-softmmu/qemu- system-s390x sh4-softmmu/qemu-system-sh4 sh4eb-softmmu/qemu-system- sh4eb sparc-softmmu/qemu-system-sparc sparc64-softmmu/qemu-system- sparc64 x86_64-softmmu/qemu-system-x86_64 xtensa-softmmu/qemu-system- xtensa xtensaeb-softmmu/qemu-system-xtensaeb Notice -softmmu being a common factor here. The size of the allocation for the temporary buffer for dumping using snprintf is determined based on the size of the buffer via call to scsi_cdb_length. I believe the heavy inlining and constant propagation makes scsi_cdb_length return -1, so len = -1. Then allocation size is 5*len + 1, or -4. Which overflows to 2^64 - 4 or so. The case of len==-1 from scsi_cdb_length happens if the (buf[0] >> 5) is not 0, 1, 2, 4 or 5. However, I can't find out how gcc figures out that buf[0] is not one of these variables. To me looking at this function, compiler should not know anything about buf[0]. I tried following the chain of calls back, including devirtualize alloc_req, and I found scsi_device_alloc_req calling these alloc_req callbacks, but it is itself called from scsi_req_new, which is called in get_scsi_requests , just after buf is filled from QEMUFile using qemu_get_buffer, which ultimately goes even further into read paths, which there might be many AFAIK. glib2 version 2.62.1-1 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1849894/+subscriptions
[Bug 1534978] Re: Windows command line -name cannot use = sign
Cannot reproduce in recent version - please close. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1534978 Title: Windows command line -name cannot use = sign Status in QEMU: Incomplete Bug description: Windows command line: qemu.exe -L . -name "32-bit Emulation Session RAM=500MB" -boot c -m 500 -drive file=\\.\PhysicalDrive2 This fails to run. If I remove the = sign in the -name quoted string it runs OK. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1534978/+subscriptions
Re: [PATCH v3 04/33] block/nbd: nbd_client_handshake(): fix leak of s->ioc
On Fri, Apr 16, 2021 at 11:08:42AM +0300, Vladimir Sementsov-Ogievskiy wrote: > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > block/nbd.c | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Roman Kagan
[Bug 1851972] Re: pc-q35-4.1 and AMD Navi 5700/XT incompatible
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1851972 Title: pc-q35-4.1 and AMD Navi 5700/XT incompatible Status in QEMU: Incomplete Bug description: Hello, I am not sure if this qualifies as a "bug"; it is be more of an unknown issue with default settings. However, since the default value of q35 default_kernel_irqchip_split was changed seemingly due to similar user feedback, I thought this was important to share.. AMD Navi 5700/XT vfio-pci passthrough seems incompatible with one/multiple settings in pc-q35-3.1 and higher. The workaround for me is that pc-q35-3.0 still works fine passing through the GPU and official drivers can load/install fine. The default/generic GPU drivers in a Fedora 30 or Windows 1903 guest do work; the monitor displays the desktop in a 800x600 resolution and things are rendered fine.. so the basic functionality of the card seems fine with pc-q35-4.1. But attempting to use the official open source AMD driver with the card resulted in a hung kernel for the Fedora 30 guest.. and a BSOD on the Windows 1903 guest immediately during driver install. I do not see any errors in Qemu command output.. did not investigate other logs or KVM etc, because I am not sure what to look for or how to go about it. Also not sure which combination of the latest q35 default settings are valid combinations to try either, because it seems that multiple things have changed related to pcie-root-port defaults and other machine options. I am happy to run tests and provide feedback if that helps identify the issue. I am using "Linux arch 5.4.0-rc6-mainline" kernel on ArchLinux host with AMD Navi reset pci quirk patch applied. My working Qemu command line is this: QEMU_AUDIO_DRV=pa \ QEMU_PA_SERVER=/run/user/1000/pulse/native \ /usr/bin/qemu-system-x86_64 \ -name windows \ -m 16g \ -accel kvm \ -machine pc-q35-3.0,accel=kvm,pflash0=ovmf0,pflash1=ovmf1 \ -blockdev node-name=ovmf0,driver=file,filename=/virt/qemu/roms/OVMF_CODE.fd,read-only=on \ -blockdev node-name=ovmf1,driver=file,filename=/virt/qemu/machines/windows/OVMF_VARS.fd \ -boot menu=on \ -global kvm-pit.lost_tick_policy=discard \ -no-hpet \ -rtc base=utc,clock=host,driftfix=slew \ -cpu host,kvm=off,hv_vendor_id=RedHatRedHat,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_reset,hv_vpindex,hv_runtime,hv_relaxed,hv_synic,hv_stimer \ -smp sockets=1,cores=4,threads=1 \ -nodefaults \ -netdev bridge,br=br0,id=net0 \ -device virtio-net-pci,netdev=net0,addr=19.0,mac=52:54:00:12:34:77 \ -device virtio-scsi-pci \ -blockdev raw,node-name=disk0,cache.direct=off,discard=unmap,file.driver=file,file.aio=threads,file.filename=/virt/qemu/machines/windows/os.raw \ -device scsi-hd,drive=disk0,rotation_rate=1 \ -blockdev raw,node-name=disk1,cache.direct=off,discard=unmap,file.driver=file,file.aio=threads,file.filename=/virt/qemu/machines/windows/data.raw \ -device scsi-hd,drive=disk1,rotation_rate=1 \ -drive index=0,if=ide,media=cdrom,readonly,file=/virt/qemu/isos/Win10_1903_V2_English_x64.iso \ -drive index=1,if=ide,media=cdrom,readonly,file=/virt/qemu/isos/virtio-win-0.1.173.iso \ -device ich9-intel-hda,addr=1b.0 \ -device hda-output \ -monitor stdio \ -display none \ -vga none \ -device pcie-root-port,id=pcierp0,chassis=1,slot=1,addr=1c.0,disable-acs=on,multifunction=on \ -device pcie-root-port,id=pcierp1,chassis=2,slot=2,addr=1c.1,disable-acs=on \ -device x3130-upstream,bus=pcierp0,id=pcieu0 \ -device xio3130-downstream,bus=pcieu0,id=pcied0,chassis=11,slot=11 \ -device vfio-pci,host=03:00.0,bus=pcied0,addr=00.0,multifunction=on \ -device vfio-pci,host=03:00.1,bus=pcied0,addr=00.1 \ -device qemu-xhci,addr=1d.0 \ -device usb-host,vendorid=0x258a,productid=0x0001 \ -device usb-host,vendorid=0x1bcf,productid=0x0005 ; Thank you! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1851972/+subscriptions
[Bug 1851845] Re: Windows 10 panics with BlueIris
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1851845 Title: Windows 10 panics with BlueIris Status in QEMU: Incomplete Bug description: Running Windows 10 64bit. Starting BlueIris 64 bit causes Windows to panic with CPU type is set higher than Penryn or CPU type = host. I have been able to reproduce the same issue on Proxmox 4,5,6 as well as oVirt 3. and 4. Does not panic when CPU type is set to kvm64. pve-qemu-kvm/stable 4.0.1-4 amd64 /usr/bin/kvm -id 102 -name win7-01 -chardev socket,id=qmp,path=/var/run/qemu-server/102.qmp,server,nowait -mon chardev=qmp,mode=control -chardev socket,id=qmp- event,path=/var/run/qmeventd.sock,reconnect=5 -mon chardev=qmp- event,mode=control -pidfile /var/run/qemu-server/102.pid -daemonize -smbios type=1,uuid=3ec61114-c30c-4719-aa00-f3f05be22d48 -smp 8,sockets=1,cores=8,maxcpus=8 -nodefaults -boot menu=on,strict=on ,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg -vnc unix:/var/run/qemu-server/102.vnc,password -no-hpet -cpu penryn,+lahf_lm,+sep,+kvm_pv_unhalt,+kvm_pv_eoi,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_reset,hv_vpindex,hv_runtime,hv_relaxed,hv_synic,hv_stimer,hv_ipi,enforce -m 12000 -device pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f -device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e -device vmgenid,guid=50deb929-1974-4fd0-9ad3-71722149d568 -device piix3-usb- uhci,id=uhci,bus=pci.0,addr=0x1.0x2 -device usb- tablet,id=tablet,bus=uhci.0,port=1 -device VGA,id=vga,bus=pci.0,addr=0x2 -chardev socket,path=/var/run/qemu- server/102.qga,server,nowait,id=qga0 -device virtio- serial,id=qga0,bus=pci.0,addr=0x8 -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 -iscsi initiator- name=iqn.1993-08.org.debian:01:203582cea152 -drive if=none,id=drive- ide2,media=cdrom,aio=threads -device ide-cd,bus=ide.1,unit=0,drive =drive-ide2,id=ide2,bootindex=200 -drive file=/disk02/prox/images/102/vm-102-disk-0.raw,if=none,id=drive- virtio0,cache=writeback,format=raw,aio=threads,detect-zeroes=on -device virtio-blk-pci,drive=drive- virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100 -drive file=/dev/disk/by-id/ata-WDC_WD80EMAZ-00WJTA0_7SGZLHYC- part1,if=none,id=drive-virtio1,cache=writeback,format=raw,aio=threads ,detect-zeroes=on -device virtio-blk-pci,drive=drive- virtio1,id=virtio1,bus=pci.0,addr=0xb -netdev type=tap,id=net0,ifname=tap102i0,script=/var/lib/qemu-server/pve- bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on -device virtio-net- pci,mac=1e:be:cb:0b:6f:13,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300 -netdev type=tap,id=net1,ifname=tap102i1,script=/var/lib/qemu-server /pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on -device virtio-net- pci,mac=EA:76:56:16:2F:D7,netdev=net1,bus=pci.0,addr=0x13,id=net1,bootindex=301 -rtc driftfix=slew,base=localtime -machine type=pc -global kvm- pit.lost_tick_policy=discard To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1851845/+subscriptions
[Bug 1851547] Re: qemu 4 crashes with this parameter attached -usb -device usb-host, hostbus=1, hostaddr=7 \
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1851547 Title: qemu 4 crashes with this parameter attached -usb -device usb- host,hostbus=1,hostaddr=7 \ Status in QEMU: Incomplete Bug description: Hello. qemu / kvm does not start anymore after upgrading ubuntu from 19.04 to 19.10 and qemu from 3 to 4,as you can see below. what can I do ? root@ziomario-Z390-AORUS-PRO:/home/ziomario/Scrivania/OS-KVM# ./boot- OS-HSP2.sh > qemu-system-x86_64: /build/qemu- UryNDZ/qemu-4.0+dfsg/hw/usb/core.c:720: usb_ep_get: asserzione "dev != NULL" non riuscita. ./boot-OS-HSP2.sh: riga 40: 26312 Annullato (core dump creato) qemu- system-x86_64 -enable-kvm -m 16000 -cpu Penryn,kvm=on,vendor=GenuineIntel,+invtsc,vmware-cpuid- freq=on,$MY_OPTIONS -machine pc-q35-2.9 -smp 4,cores=2 -vga none -device vfio-pci,host=01:00.0,bus=pcie.0,multifunction=on -device vfio-pci,host=01:00.1,bus=pcie.0 -device vfio- pci,host=01:00.2,bus=pcie.0 -device vfio-pci,host=01:00.3,bus=pcie.0 -usb -device usb-host,hostbus=1,hostaddr=7 -drive if=pflash,format=raw,readonly,file=$OVMF/OVMF_CODE.fd -drive if=pflash,format=raw,file=$OVMF/OVMF_VARS-1024x768.fd -smbios type=2 -device ich9-ahci,id=sata -drive id=Clover,if=none,snapshot=on,format=qcow2,file=./'Mo/CloverNG.qcow2' -device ide-hd,bus=sata.2,drive=Clover -device ide- hd,bus=sata.3,drive=InstallMedia -drive id=InstallMedia,if=none,file=BaseSystemHS.img,format=raw -drive id=BsdHDD,if=none,file=/dev/sdg,format=raw -device ide- hd,bus=sata.4,drive=BsdHDD -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -device e1000-82545em,netdev=net0,id=net0,mac=52:54:00:c9:18:27 -monitor stdio It seems that this line is not good anymore (it worked with qemu 3.x) : -usb -device usb-host,hostbus=1,hostaddr=7 \ when I removed it,it works. But I need that. With what can I change it ? You can reproduce that upgrading ubuntu 19.04 to 19.10 because in that way also qemu will be upgraded from 3 to 4. These are the packages that I'm using : root@ziomario-Z390-AORUS-PRO:/home/ziomario# qemu-system-x86_64 --version QEMU emulator version 4.0.0 (Debian 1:4.0+dfsg-0ubuntu9) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1851547/+subscriptions
Re: [PATCH v6] qapi: introduce 'query-cpu-model-cpuid' action
On Wed, Apr 21, 2021 at 04:17:59PM -0400, Eduardo Habkost wrote:
> On Wed, Apr 21, 2021 at 08:39:42PM +0300, Valeriy Vdovin wrote:
> > On Tue, Apr 20, 2021 at 01:09:00PM -0400, Eduardo Habkost wrote:
> > > On Tue, Apr 20, 2021 at 07:19:40PM +0300, Valeriy Vdovin wrote:
> > > [...]
> > > > +##
> > > > +# @query-cpu-model-cpuid:
> > > > +#
> > > > +# Returns description of a virtual CPU model, created by QEMU after cpu
> > > > +# initialization routines. The resulting information is a reflection
> > > > of a parsed
> > > > +# '-cpu' command line option, filtered by available host cpu features.
> > > > +#
> > > > +# Returns: @CpuModelCpuidDescription
> > > > +#
> > > > +# Example:
> > > > +#
> > > > +# -> { "execute": "query-cpu-model-cpuid" }
> > > > +# <- { "return": 'CpuModelCpuidDescription' }
> > > > +#
> > > > +# Since: 6.1
> > > > +##
> > > > +{ 'command': 'query-cpu-model-cpuid',
> > > > + 'returns': 'CpuModelCpuidDescription',
> > > > + 'if': 'defined(TARGET_I386)' }
> > >
> > > I was assuming the command was going to get a CPU model name as
> > > argument.
> > >
> > > If you are only going to return info on the current CPUs, the
> > > interface could be simplified a lot.
> > >
> > > What about a simple `query-cpuid` command that only takes:
> > >
> > > { 'qom-path': 'str', # qom-path is returned by query-cpus-fast
> > >'eax': 'uint32',
> > >'*ecx': 'uint32' }
> > >
> > > as argument, and returns
> > >
> > > { 'present': 'bool',
> > >'max_eax': 'uint32',# max value of EAX for this range
> > >'*max_ecx': 'uint32', # max value of ECX if there are subleaves
> > >'eax': 'uint32',
> > >'ebx': 'uint32',
> > >'ecx': 'uint32',
> > >'edx': 'uint32' }
> > >
> > > ?
> > Hi. The interface that you suggest looks good. But it has one critical
> > point that deems it unusable for our initial needs. The point of this
> > whole new API is to take away the strain of knowing about leaf ranges
> > from the caller of this API. In my current patch this goal works. So
> > the caller does not need to know in advance what ranges there are in
> > original CPUID as well as in it's tweaked QEMU's version.
> >
>
> Raw CPUID data is a pretty low level interface, already. Is it
> really too much of a burden for callers to know that CPUID ranges
> start at 0, 0x4000, 0x8000, and 0xC000?
>
> (Especially considering that it would save us ~100 extra lines of
> C code and maybe 50-100 extra lines of QAPI schema code.)
>
>
> > But you suggested API is not so kind to the caller, so he would need
> > to add some logic around the call that knows about exact leaf ranges.
> > If you have a solution to that also, I'll be happy to discuss it.
>
> Would be following (Python-like pseudocode) be too much of a
> burden for consumers of the command?
>
> for start in (0, 0x4000, 0x8000, 0xC000):
> leaf = query_cpuid(qom_path, start)
> for eax in range(start, leaf.max_eax + 1):
> for ecx in range(0, leaf.get('max_ecx', 0) + 1):
> all_leaves.append(query_cpuid(qom_path, eax, ecx))
>
This is a question of architecture and design. Number of lines is
secondary (up to some reasonable point of course).
I want to decouple components as much as possible. It's not a burden to pass
4 digits once you know them, but how exactly should a caller come to these 4
digits? It's like a password. It's easy once you know it. Check out Intel's
Instruction Set Manual on CPUID - obvious place to learn about ranges for the
caller, yet you wont see exactly these numbers in plain text. And where is
0x4000 in this manual exactly? One should read QEMU git history to know
what it is. Correct me here if I'm wrong.
The work of figuring out the required ranges should not be duplicated without
need. QEMU does that already, there is a nice way of passing them to the caller,
and it makes component interaction more generic (no private knowledge pased),
so why not do that.
Please take into account the design of applications that will use this
method. With less restrictive API, components could be more isolated, for
example one component could only know how to call qmp methods, the other would
have to khow how to process CPUID data, resulting in a clean layered
architecture.
Also I'm not sure that these ranges would never change. Are you sure that some
other range won't appear soon? If so, shouldn't we try to make less locations,
where this would have to be supported?
So my pros are: loose coupling / generic interface, less places to
maintain in case of chages. These are pretty basic.
Cons: more lines of code as you've said, but otherwize more code will be
in the callers, and more callers == more duplicated code.
Thanks.
> >
> > The obvious thing that comes to mind is changing the exists/max_ecx pair
> > to something like next_eax, next_ecx. But this idea will probably require
> > the same amount of complexity that I currently have in this patch
[Bug 1850378] Re: RISC-V unreliable IPIs
The QEMU project is currently considering to move its bug tracking to
another system. For this we need to know which bugs are still valid
and which could be closed already. Thus we are setting older bugs to
"Incomplete" now.
If you still think this bug report here is valid, then please switch
the state back to "New" within the next 60 days, otherwise this report
will be marked as "Expired". Or please mark it as "Fix Released" if
the problem has been solved with a newer version of QEMU already.
Thank you and sorry for the inconvenience.
** 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/1850378
Title:
RISC-V unreliable IPIs
Status in QEMU:
Incomplete
Bug description:
I am working on a project with custom inter processor interrupts (IPIs) on
the RISC-V virt machine.
After upgrading from version 3.1.0 to 4.1.0 which fixes a related issue
(https://github.com/riscv/riscv-qemu/issues/132) I am able to use the CPU
hotplug feature.
However, if I try to use IPIs for communication between two cores, the
wfi instruction behaves strangely. Either it does not return, or it
returns on timer interrupts, even though they are disabled. The code,
I use on one core to wait for an interrupt is the following.
csr_clear(sie, SIE_SEIE | SIE_STIE);
do {
wait_for_interrupt();
sipval = csr_read(sip);
sieval = csr_read(sie);
scauseval = csr_read(scause) & 0xFF;
/* only break if wfi returns for an software interrupt */
} while ((sipval & sieval) == 0 && scauseval != 1);
csr_set(sie, SIE_SEIE | SIE_STIE);
Since the resulting sequence does not seem to be deterministic, my
guess is, that it has something to do with the communication of qemu's
threads for the different cores.
Update:
The exact same setup works fine in spike (the actual sim, not the qemu
board), which might give a hint, that it is related to the interrupt controller
implementation.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1850378/+subscriptions
[Bug 1850751] Re: kvm flag is not exposed by default
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1850751 Title: kvm flag is not exposed by default Status in QEMU: Incomplete Bug description: Hi I found that the kvm flags is not exposed by default, but according to the source code, it should be exposed by default when the CPU Model is a X86CPU. we have to specifically add "kvm=on" in QEMU custom cpu args like this to make VMWare Timing and KVM-Clock work: Also the libvirt can't expose kvm because of this (libvirt assumes the kvm flag is exposed by default in QEMU, so only "kvm hidden = 'true'" can be used to disable the kvm expose flag. I'm using QEMU 4.1.0 and libvirt 20190803. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1850751/+subscriptions
[Bug 1925449] [NEW] Failure building with clang-10 and libssh
Public bug reported: On Fedora 32, configuring with --enable-libssh and building with clang: qemu 5.2.94 Compilation host CPU : x86_64 host endianness : little C compiler : clang-10 Host C compiler : clang-10 Dependencies libssh support : YES triggers: FAILED: libblock.fa.p/block_ssh.c.o block/ssh.c:349:13: error: 'ssh_is_server_known' is deprecated [-Werror,-Wdeprecated-declarations] state = ssh_is_server_known(s->session); ^ /usr/include/libssh/libssh.h:546:1: note: 'ssh_is_server_known' has been explicitly marked deprecated here SSH_DEPRECATED LIBSSH_API int ssh_is_server_known(ssh_session session); ^ /usr/include/libssh/libssh.h:84:40: note: expanded from macro 'SSH_DEPRECATED' #define SSH_DEPRECATED __attribute__ ((deprecated)) ^ block/ssh.c:444:9: error: 'ssh_get_publickey' is deprecated [-Werror,-Wdeprecated-declarations] r = ssh_get_publickey(s->session, &pubkey); ^ /usr/include/libssh/libssh.h:543:1: note: 'ssh_get_publickey' has been explicitly marked deprecated here SSH_DEPRECATED LIBSSH_API int ssh_get_publickey(ssh_session session, ssh_key *key); ^ /usr/include/libssh/libssh.h:84:40: note: expanded from macro 'SSH_DEPRECATED' #define SSH_DEPRECATED __attribute__ ((deprecated)) ^ 2 errors generated. ** 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.net/bugs/1925449 Title: Failure building with clang-10 and libssh Status in QEMU: New Bug description: On Fedora 32, configuring with --enable-libssh and building with clang: qemu 5.2.94 Compilation host CPU : x86_64 host endianness : little C compiler : clang-10 Host C compiler : clang-10 Dependencies libssh support : YES triggers: FAILED: libblock.fa.p/block_ssh.c.o block/ssh.c:349:13: error: 'ssh_is_server_known' is deprecated [-Werror,-Wdeprecated-declarations] state = ssh_is_server_known(s->session); ^ /usr/include/libssh/libssh.h:546:1: note: 'ssh_is_server_known' has been explicitly marked deprecated here SSH_DEPRECATED LIBSSH_API int ssh_is_server_known(ssh_session session); ^ /usr/include/libssh/libssh.h:84:40: note: expanded from macro 'SSH_DEPRECATED' #define SSH_DEPRECATED __attribute__ ((deprecated)) ^ block/ssh.c:444:9: error: 'ssh_get_publickey' is deprecated [-Werror,-Wdeprecated-declarations] r = ssh_get_publickey(s->session, &pubkey); ^ /usr/include/libssh/libssh.h:543:1: note: 'ssh_get_publickey' has been explicitly marked deprecated here SSH_DEPRECATED LIBSSH_API int ssh_get_publickey(ssh_session session, ssh_key *key); ^ /usr/include/libssh/libssh.h:84:40: note: expanded from macro 'SSH_DEPRECATED' #define SSH_DEPRECATED __attribute__ ((deprecated)) ^ 2 errors generated. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1925449/+subscriptions
[Bug 1853898] Re: qemu/hw/scsi/lsi53c895a.c:417: lsi_soft_reset: Assertion `QTAILQ_EMPTY(&s->queue)' failed.
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1853898 Title: qemu/hw/scsi/lsi53c895a.c:417: lsi_soft_reset: Assertion `QTAILQ_EMPTY(&s->queue)' failed. Status in QEMU: Incomplete Bug description: While experimenting with blkdebug I can consistently hit this assertion in lsi53c895a.c. Using locally built from master, commit: 2061735ff09f9d5e67c501a96227b470e7de69b1 Steps to reproduce $ qemu-img create -f raw empty.raw 8G $ sudo losetup -f --show empty.raw $ sudo mkfs.ext3 /dev/loop0 $ sudo losetup -D $ cat blkdebug.conf [inject-error] event = "read_aio" errno = "5" $ qemu-system-x86_64 -enable-kvm -m 2048 -cpu host -smp 4 -nic user,ipv6=off,model=e1000,hostfwd=tcp::-:22,net=172.16.0.0/255.255.255.0 -device lsi53c895a,id=scsi -device scsi-hd,drive=hd,wwn=12345678 -drive if=scsi,id=hd,file=blkdebug:blkdebug.conf:empty.raw,cache=none,format=raw -cdrom Fedora-Server-dvd-x86_64-31-1.9.iso -display gtk Initiate install from cdrom ISO image results in: qemu-system-x86_64: /builddir/build/BUILD/qemu-3.1.1/hw/scsi/lsi53c895a.c:381: lsi_soft_reset: Assertion `QTAILQ_EMPTY(&s->queue)' failed. Aborted (core dumped) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1853898/+subscriptions
[Bug 1853429] Re: qemu-kvm on aarch64 attach volume failed when vm is booting
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1853429 Title: qemu-kvm on aarch64 attach volume failed when vm is booting Status in QEMU: Incomplete Bug description: I use libvirt and qemu-kvm on aarch64 platform to attach volume to a booting vm，when the system of vm has not boot up, attach volume will be failed, after vm system booting up, attach volume can be successful. libvirt: 4.5.0 qemu : 2.12.0 console log and qemu command of vm is in attachment. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1853429/+subscriptions
[Bug 1855535] Re: Connection reset by peer when using port fwd
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1855535 Title: Connection reset by peer when using port fwd Status in QEMU: Incomplete Bug description: $ qemu-system-ppc64 -cpu POWER8,compat=power7 -machine pseries -m 8G -smp cores=8 -serial mon:stdio -nographic \ -drive file=/qemu/aix72.img,if=none,id=drive-virtio-disk0 \ -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 \ -cdrom /qemu/aix72.iso \ -prom-env boot-command='boot disk:' \ -name ctsprod -k es \ -netdev user,id=netdev0,hostfwd=tcp:127.0.0.1:-:22 \ -device virtio-net-pci,netdev=netdev0 \ -netdev bridge,id=hostnet0,br=virbr0 \ -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:96:2f:7a \ -device virtio-net,netdev=vmnic -netdev tap,id=vmnic,ifname=vnet0,script=no,downscript=no \ -monitor telnet:127.0.0.1:5801,server,nowait,nodelay $ ssh -p root@127.0.0.1 -v OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to 127.0.0.1 [127.0.0.1] port . debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 ssh_exchange_identification: read: Connection reset by peer To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1855535/+subscriptions
[Bug 1854878] Re: Physical USB thumbdrive treated as read-only
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1854878 Title: Physical USB thumbdrive treated as read-only Status in QEMU: Incomplete Bug description: So I have installed FreeDOS on my USB thumbdrive, by using Rufus. Everything goes as expected so far. That's good. When I run QEMU with this command line: qemu-system-x86_64.exe -drive file=\\.\PhysicalDrive1 it of course is read-only, just like the resulting console message says: WARNING: Image format was not specified for '\\.\PhysicalDrive1' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions. So what I then did, was I ran QEMU with this command line: qemu-system-x86_64.exe -drive file=\\.\PhysicalDrive1,format=raw As expected, the above mentioned console message no longer appears. However, beyond that, QEMU doesn't behave as it should regarding read-only status. When I try any operation that involves writing to the drive, it becomes quite clear that the drive is still read-only. Any writing operations to the drive result in FreeDOS giving me the error message: Error writing to drive C: DOS area: sector not found. The above situation is clearly a bug. QEMU should not be treating it as read-only once I specify format=raw. Note that drive C is how the guest OS refers to the USB thumbdrive (it's drive E in my host OS, and drive C in my host OS is the actual system drive). And yes, it is a QEMU bug. It's not a FreeDOS bug I tested it with this command line, so that all changes would be written to a temporary snapshot file: qemu-system-x86_64.exe -drive file=\\.\PhysicalDrive1,format=raw,snapshot That last drive option "snapshot" tells QEMU to create a temporary snapshot file, and to write all changes to that. When I do that, all write operations are successful. So it seems that there is a bug in QEMU where it keeps read-only mode in place for a physical drive, even when format=raw is specified. Please fix this bug. Thanks in advance. Here's my current setup. Host OS: Windows 10 (64bit) Guest OS: FreeDOS QEMU version: 4.1.0 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1854878/+subscriptions
[Bug 1854910] Re: Support VHDX differencing images (ie images with backing)
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** Changed in: qemu Status: New => Incomplete ** Changed in: qemu Importance: Undecided => Wishlist -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1854910 Title: Support VHDX differencing images (ie images with backing) Status in QEMU: Incomplete Bug description: The qemu vhdx driver does not support type 2 (differencing) vhdx images (usually stored with file extension .avhdx). This means that any hyperv images with snapshots are not supported by qemu-img. It would be great to be able to convert to a new qcow image from a backing + set of differencing images from hyperv, and/or convert an individual differencing vhdx image to a qcow2 image with a backing file specified. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1854910/+subscriptions
[Bug 1854738] Re: ppc doesn't support for mttcg but ppc64 supported
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1854738 Title: ppc doesn't support for mttcg but ppc64 supported Status in QEMU: Incomplete Bug description: Currently ppc and ppc64abi32 doesn't suppport for mttcg, I am looking for support ``` ppc) gdb_xml_files="power-core.xml power-fpu.xml power-altivec.xml power-spe.xml" ;; ppc64) TARGET_BASE_ARCH=ppc TARGET_ABI_DIR=ppc mttcg=yes gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml power-vsx.xml" ;; ppc64le) TARGET_ARCH=ppc64 TARGET_BASE_ARCH=ppc TARGET_ABI_DIR=ppc mttcg=yes gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml power-vsx.xml" ;; ppc64abi32) TARGET_ARCH=ppc64 TARGET_BASE_ARCH=ppc TARGET_ABI_DIR=ppc echo "TARGET_ABI32=y" >> $config_target_mak gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml power-vsx.xml" ;; ``` To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1854738/+subscriptions
[Bug 1854204] Re: Menu is not clickable on OSX Catalina
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1854204 Title: Menu is not clickable on OSX Catalina Status in QEMU: Incomplete Bug description: 1) Run `qemu-system-x86_64` 2) Try to click on the main menu Menu is not clickable until another window is activated and QEMU window is activated again To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1854204/+subscriptions
Re: [PATCH] tcg/ppc: Fix building with Clang
On Thu, 22 Apr 2021 at 06:18, Richard Henderson wrote: > > On 4/21/21 2:03 AM, Peter Maydell wrote: > >> +/* Clang does not define _CALL_* */ > >> +#if defined(__clang__) && defined(__ELF__) && !defined(_CALL_SYSV) > >> +#define _CALL_SYSV 1 > >> +#endif > > > > This is trying to identify the calling convention used by the OS. > > That's not purely compiler specific (ie it is not the case that > > all ELF output from clang is definitely using the calling convention > > that _CALL_SYSV implies), so settign it purely based on "this is clang > > producing ELF files" doesn't seem right. > > We can get pretty close though. There are three ppc32 calling conventions: > AIX, DARWIN, SYSV. The _CALL_ELF symbol is a 64-bit thing, and AIX itself > doesn't use ELF. > > > I guess if clang doesn't reliably tell us the calling convention > > maybe we should scrap the use of _CALL_SYSV and _CALL_ELF and > > use the host OS defines to guess the calling convention ? > > No, I'd rely on _CALL_* first, and only fall back to something else if they're > not present. > > I'm thinking something like > > #if !defined(_CALL_SYSV) && \ > !defined(_CALL_DARWIN) && \ > !defined(_CALL_AIX) && \ > !defined(_CALL_ELF) > # if defined(__APPLE__) > # define _CALL_DARWIN > # elif defined(__ELF__) && TCG_TARGET_REG_BITS == 32 > # define _CALL_SYSV > # else > # error "Unknown ABI" > # endif > #endif Doesn't this also need some case that handles "64bit ppc clang which doesn't define _CALL_anything" ? thanks -- PMM
[Bug 1868221] Re: /usr/share/applications/qemu.desktop should have an "Exec=" key.
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1868221 Title: /usr/share/applications/qemu.desktop should have an "Exec=" key. Status in QEMU: Incomplete Bug description: According to the www.freedesktop.org .desktop-file specification, all "Application" desktop files should have an "Exec=" key. The one in qemu doesn't. This can be easily verified by running kbuildsycoca4 if KDE4 is present, but the issue is not DE-dependent. Which binary exactly should be assigned as the default one, I don't know. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1868221/+subscriptions
[Bug 1853123] Re: Memory synchronization error between kvm and target, e1000(dpdk)
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1853123 Title: Memory synchronization error between kvm and target, e1000(dpdk) Status in QEMU: Incomplete Bug description: Hi folks. I use linux with dpdk drivers on the target system, and e1000 emulation device with tap interface for host. I use kvm for accelerate. Version qemu 4.0.94 and master (Nov 12 10:14:33 2019) Version dpdk stable-17.11.4 Version linux host 4.15.0-66-generic (ubuntu 18.04) I type command "ping -f" and wait about 1-2 minutes. Network subsystem freezes. For receive the eth pack from host system (tap interface) to host system the e1000 using ring buffer. The e1000 write body of eth pack, set E1000_RXD_STAT_DD flag and move RDH (Ring Device Head). (file hw/net/e1000.c function e1000_receive_iov() ) The dpdk driver is reading from E1000_RXD_STAT_DD flags (ignoring RDH), if flag is set: read buffer, unset flag E1000_RXD_STAT_DD and move RDT (Ring Device Tail). (source drivers/net/e1000/em_rxtx.c function eth_em_recv_scattered_pkts() ) I see what the driver unet E1000_RXD_STAT_DD (rxdp->status = 0; ), but sometimes rxdp->status remains equal to 7. On the next cycle, this this buffer is read, RDT moved to far. RDH becomes equal RDT and network is freezes. If I insert some delay after unset E1000_RXD_STAT_DD, and repeatedly unset E1000_RXD_STAT_DD (if rxdp->status == 7 ), then all work fine. If check E1000_RXD_STAT_DD without delay, status rxdp->status always valid. This only appears on kvm. If I use tcg all works fine. I trying set watchpoint for memory on the qemu (for tcg), and see, that for one package cycle of set/unse STAT_DD repeated once. I trying set watchpoint for memory on the qemu (for kvm), and see, that rxdp->status changed to 0(unset) only once, but is changes immediately before set flag. Please help me with advice on how to catch and fix this error. Theoretically, it would help me to trace the memory access when writing to E1000_RXD_STAT_DD, RHD and RDT, both from the target and the host system. But I have no idea how this can be done. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1853123/+subscriptions
[Bug 1870911] Re: QEMU Crashes on Launch, Windows
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1870911 Title: QEMU Crashes on Launch, Windows Status in QEMU: Incomplete Bug description: Hi, I an having no issues up to (and including) v5.0.0-rc0, but when I move to rc1 ... it won't even execute in Windows. If I just try to, for example, run qemu-system-x86_64.exe --version No output, it just exits. This seems to be new with this version. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1870911/+subscriptions
[Bug 1855617] Re: savevm with hax saves wrong register state
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** 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/1855617 Title: savevm with hax saves wrong register state Status in QEMU: Incomplete Bug description: I use qemu-i386 with IntelHaxm on Windows 10 x64 host with Windows 7 x86 guest. I run the guest till OS loads and create a snapshot with savevm, then close qemu, run it again and try to load the snapshot with loadvm. The guest crashes or freezes. I dumped registers on snapshot creation and loading (in Haxm) and found that they are different. When returning from Haxm in hax_vcpu_hax_exec, there is no regular register read. I found hax_arch_get_registers function which reads registers from Haxm and is called from a synchronization procedure. I placed a breakpoint on it, ran qemu and found that it is hit one time during guest OS boot. Exactly these registers where saved in the snapshot. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1855617/+subscriptions
Re: [Virtio-fs] [PATCH v2 17/25] DAX/unmap: virtiofsd: Add VHOST_USER_SLAVE_FS_IO
* Vivek Goyal (vgo...@redhat.com) wrote:
> On Wed, Apr 14, 2021 at 04:51:29PM +0100, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > Define a new slave command 'VHOST_USER_SLAVE_FS_IO' for a
> > client to ask qemu to perform a read/write from an fd directly
> > to GPA.
>
> Hi David,
>
> Today I came across process_vm_readv() and process_vm_writev().
>
> https://man7.org/linux/man-pages/man2/process_vm_readv.2.html
Yes, I just saw these (reading the lwn article on process_vm_exec)
> I am wondering if we can use these to read from/write to qemu address
> space (DAX window, which virtiofsd does not have access to).
>
> So for the case of reading from DAX window into an fd, we probably
> will have to first read from qemu DAX window to virtiofsd local memory
> and then do a writev(fd).
>
> Don't know if this approach is faster/slower as compared to sending
> a vhost-user message to qemu.
I think there are some other problems as well:
a) I'm not sure the permissions currently work out - I think it's
saying you need to either have CAP_SYS_PTRACE or the same uid as the
other process; and I don't think that's normally the relationship
between the daemon and the qemu.
b) The virtiofsd would have to know something about the addresses in
qemu's address space, rather than currently only knowing guest
addresses.
c) No one said that mapping is linear/simple, especially for an area
where an fd wasn't passed for shared memory.
Also, this interface does protect qemu from the daemon writing to
arbitrary qemu data strctures.
Still, those interfaces do sound attractive for something - just not
quite figured out what.
Dave
> Thanks
> Vivek
>
>
> >
> > Signed-off-by: Dr. David Alan Gilbert
> > ---
> > docs/interop/vhost-user.rst | 16
> > hw/virtio/trace-events| 6 ++
> > hw/virtio/vhost-user-fs.c | 95 +++
> > hw/virtio/vhost-user.c| 4 +
> > include/hw/virtio/vhost-user-fs.h | 2 +
> > subprojects/libvhost-user/libvhost-user.h | 1 +
> > 6 files changed, 124 insertions(+)
> >
> > diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst
> > index 09aee3565d..2fa62ea451 100644
> > --- a/docs/interop/vhost-user.rst
> > +++ b/docs/interop/vhost-user.rst
> > @@ -1453,6 +1453,22 @@ Slave message types
> >multiple chunks can be unmapped in one command.
> >A reply is generated indicating whether unmapping succeeded.
> >
> > +``VHOST_USER_SLAVE_FS_IO``
> > + :id: 9
> > + :equivalent ioctl: N/A
> > + :slave payload: ``struct VhostUserFSSlaveMsg``
> > + :master payload: N/A
> > +
> > + Requests that IO be performed directly from an fd, passed in ancillary
> > + data, to guest memory on behalf of the daemon; this is normally for a
> > + case where a memory region isn't visible to the daemon. slave payload
> > + has flags which determine the direction of IO operation.
> > +
> > + The ``VHOST_USER_FS_FLAG_MAP_R`` flag must be set in the ``flags`` field
> > to
> > + read from the file into RAM.
> > + The ``VHOST_USER_FS_FLAG_MAP_W`` flag must be set in the ``flags`` field
> > to
> > + write to the file from RAM.
> > +
> > .. _reply_ack:
> >
> > VHOST_USER_PROTOCOL_F_REPLY_ACK
> > diff --git a/hw/virtio/trace-events b/hw/virtio/trace-events
> > index c62727f879..20557a078e 100644
> > --- a/hw/virtio/trace-events
> > +++ b/hw/virtio/trace-events
> > @@ -53,6 +53,12 @@ vhost_vdpa_get_features(void *dev, uint64_t features)
> > "dev: %p features: 0x%"PRI
> > vhost_vdpa_set_owner(void *dev) "dev: %p"
> > vhost_vdpa_vq_get_addr(void *dev, void *vq, uint64_t desc_user_addr,
> > uint64_t avail_user_addr, uint64_t used_user_addr) "dev: %p vq: %p
> > desc_user_addr: 0x%"PRIx64" avail_user_addr: 0x%"PRIx64" used_user_addr:
> > 0x%"PRIx64
> >
> > +# vhost-user-fs.c
> > +
> > +vhost_user_fs_slave_io_loop(const char *name, uint64_t owr, int is_ram,
> > int is_romd, size_t size) "region %s with internal offset 0x%"PRIx64 "
> > ram=%d romd=%d mrs.size=%zd"
> > +vhost_user_fs_slave_io_loop_res(ssize_t transferred) "%zd"
> > +vhost_user_fs_slave_io_exit(int res, size_t done) "res: %d done: %zd"
> > +
> > # virtio.c
> > virtqueue_alloc_element(void *elem, size_t sz, unsigned in_num, unsigned
> > out_num) "elem %p size %zd in_num %u out_num %u"
> > virtqueue_fill(void *vq, const void *elem, unsigned int len, unsigned int
> > idx) "vq %p elem %p len %u idx %u"
> > diff --git a/hw/virtio/vhost-user-fs.c b/hw/virtio/vhost-user-fs.c
> > index 963f694435..5511838f29 100644
> > --- a/hw/virtio/vhost-user-fs.c
> > +++ b/hw/virtio/vhost-user-fs.c
> > @@ -23,6 +23,8 @@
> > #include "hw/virtio/vhost-user-fs.h"
> > #include "monitor/monitor.h"
> > #include "sysemu/sysemu.h"
> > +#include "exec/address-spaces.h"
> > +#include "trace.h"
> >
> > static const int user_feature_bits[] = {
> > VIRTIO_F_VERSION_1,
> > @@ -220,6 +222,99 @@ uint64_t v
Re: [PATCH v3 2/3] vhost-user-blk: perform immediate cleanup if disconnect on initialization
Am 21.04.2021 um 21:59 hat Michael S. Tsirkin geschrieben:
> On Wed, Apr 21, 2021 at 07:13:24PM +0300, Denis Plotnikov wrote:
> >
> > On 21.04.2021 18:24, Kevin Wolf wrote:
> > > Am 25.03.2021 um 16:12 hat Denis Plotnikov geschrieben:
> > > > Commit 4bcad76f4c39 ("vhost-user-blk: delay vhost_user_blk_disconnect")
> > > > introduced postponing vhost_dev cleanup aiming to eliminate qemu aborts
> > > > because of connection problems with vhost-blk daemon.
> > > >
> > > > However, it introdues a new problem. Now, any communication errors
> > > > during execution of vhost_dev_init() called by
> > > > vhost_user_blk_device_realize()
> > > > lead to qemu abort on assert in vhost_dev_get_config().
> > > >
> > > > This happens because vhost_user_blk_disconnect() is postponed but
> > > > it should have dropped s->connected flag by the time
> > > > vhost_user_blk_device_realize() performs a new connection opening.
> > > > On the connection opening, vhost_dev initialization in
> > > > vhost_user_blk_connect() relies on s->connection flag and
> > > > if it's not dropped, it skips vhost_dev initialization and returns
> > > > with success. Then, vhost_user_blk_device_realize()'s execution flow
> > > > goes to vhost_dev_get_config() where it's aborted on the assert.
> > > >
> > > > To fix the problem this patch adds immediate cleanup on device
> > > > initialization(in vhost_user_blk_device_realize()) using different
> > > > event handlers for initialization and operation introduced in the
> > > > previous patch.
> > > > On initialization (in vhost_user_blk_device_realize()) we fully
> > > > control the initialization process. At that point, nobody can use the
> > > > device since it isn't initialized and we don't need to postpone any
> > > > cleanups, so we can do cleaup right away when there is a communication
> > > > problem with the vhost-blk daemon.
> > > > On operation we leave it as is, since the disconnect may happen when
> > > > the device is in use, so the device users may want to use vhost_dev's
> > > > data
> > > > to do rollback before vhost_dev is re-initialized (e.g. in
> > > > vhost_dev_set_log()).
> > > >
> > > > Signed-off-by: Denis Plotnikov
> > > > Reviewed-by: Raphael Norwitz
> > > I think there is something wrong with this patch.
> > >
> > > I'm debugging an error case, specifically num-queues being larger in
> > > QEMU that in the vhost-user-blk export. Before this patch, it has just
> > > an unfriendly error message:
> > >
> > > qemu-system-x86_64: -device
> > > vhost-user-blk-pci,chardev=vhost1,id=blk1,iommu_platform=off,disable-legacy=on,num-queues=4:
> > > Unexpected end-of-file before all data were read
> > > qemu-system-x86_64: -device
> > > vhost-user-blk-pci,chardev=vhost1,id=blk1,iommu_platform=off,disable-legacy=on,num-queues=4:
> > > Failed to read msg header. Read 0 instead of 12. Original request 24.
> > > qemu-system-x86_64: -device
> > > vhost-user-blk-pci,chardev=vhost1,id=blk1,iommu_platform=off,disable-legacy=on,num-queues=4:
> > > vhost-user-blk: get block config failed
> > > qemu-system-x86_64: Failed to set msg fds.
> > > qemu-system-x86_64: vhost VQ 0 ring restore failed: -1: Resource
> > > temporarily unavailable (11)
> > >
> > > After the patch, it crashes:
> > >
> > > #0 0x55d0a4bd in vhost_user_read_cb (source=0x568f4690,
> > > condition=(G_IO_IN | G_IO_HUP), opaque=0x7fffcbf0) at
> > > ../hw/virtio/vhost-user.c:313
> > > #1 0x55d950d3 in qio_channel_fd_source_dispatch
> > > (source=0x57c3f750, callback=0x55d0a478 ,
> > > user_data=0x7fffcbf0) at ../io/channel-watch.c:84
> > > #2 0x77b32a9f in g_main_context_dispatch () at
> > > /lib64/libglib-2.0.so.0
> > > #3 0x77b84a98 in g_main_context_iterate.constprop () at
> > > /lib64/libglib-2.0.so.0
> > > #4 0x77b32163 in g_main_loop_run () at /lib64/libglib-2.0.so.0
> > > #5 0x55d0a724 in vhost_user_read (dev=0x57bc62f8,
> > > msg=0x7fffcc50) at ../hw/virtio/vhost-user.c:402
> > > #6 0x55d0ee6b in vhost_user_get_config (dev=0x57bc62f8,
> > > config=0x57bc62ac "", config_len=60) at ../hw/virtio/vhost-user.c:2133
> > > #7 0x55d56d46 in vhost_dev_get_config (hdev=0x57bc62f8,
> > > config=0x57bc62ac "", config_len=60) at ../hw/virtio/vhost.c:1566
> > > #8 0x55cdd150 in vhost_user_blk_device_realize
> > > (dev=0x57bc60b0, errp=0x7fffcf90) at
> > > ../hw/block/vhost-user-blk.c:510
> > > #9 0x55d08f6d in virtio_device_realize (dev=0x57bc60b0,
> > > errp=0x7fffcff0) at ../hw/virtio/virtio.c:3660
> > >
> > > The problem is that vhost_user_read_cb() still accesses dev->opaque even
> > > though the device has been cleaned up meanwhile when the connection was
> > > closed (the vhost_user_blk_disconnect() added by this patch), so it's
> > > NULL now. This problem was actually mentioned in the comment that is
> > > removed by this patch.
> > >
> > > I tried to f
[Bug 1839367] Re: Wrong interrupts generated for I.MX6 FEC controller
Still a bug. ** Changed in: qemu Status: Incomplete => 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/1839367 Title: Wrong interrupts generated for I.MX6 FEC controller Status in QEMU: Confirmed Bug description: The imx_eth_update function in hw/net/imx_fec.c has the following comment (https://github.com/qemu/qemu/blob/864ab314f1d924129d06ac7b571f105a2b76a4b2/hw/net/imx_fec.c#L421-L445): /* * Previous versions of qemu had the ENET_INT_MAC and ENET_INT_MAC * interrupts swapped. This worked with older versions of Linux (4.14 * and older) since Linux associated both interrupt lines with Ethernet * MAC interrupts. Specifically, * - Linux 4.15 and later have separate interrupt handlers for the MAC and * timer interrupts. Those versions of Linux fail with versions of QEMU * with swapped interrupt assignments. * - In linux 4.14, both interrupt lines were registered with the Ethernet * MAC interrupt handler. As a result, all versions of qemu happen to * work, though that is accidental. * - In Linux 4.9 and older, the timer interrupt was registered directly * with the Ethernet MAC interrupt handler. The MAC interrupt was * redirected to a GPIO interrupt to work around erratum ERR006687. * This was implemented using the SOC's IOMUX block. In qemu, this GPIO * interrupt never fired since IOMUX is currently not supported in qemu. * Linux instead received MAC interrupts on the timer interrupt. * As a result, qemu versions with the swapped interrupt assignment work, * albeit accidentally, but qemu versions with the correct interrupt * assignment fail. * * To ensure that all versions of Linux work, generate ENET_INT_MAC * interrrupts on both interrupt lines. This should be changed if and when * qemu supports IOMUX. */ Unfortunately, this behavior causes the QNX Sabrelite BSP (http://blackberry.qnx.com/en/developers/bsp) to hang on ethernet initialization. This is caused by the fact that QEMU is firing the ENET_INT_TS_TIMER timer interrupt unexpectedly (when the ENET_INT_MAC flag is set). The BSP functions correctly on the actual hardware, but it is unable to handle the deliberately incorrect interrupt firing by QEMU. From reading the comment, it appears that this behavior is necessary to support certain versions of Linux. However, it would be very useful to be able to restore the correct interrupt behavior (possibly via a command-line flag). To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1839367/+subscriptions
[Bug 661696] Re: incomplete emulation of fstenv under TCG
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** Changed in: qemu Status: Confirmed => 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/661696 Title: incomplete emulation of fstenv under TCG Status in QEMU: Incomplete Bug description: Steps to reproduce: 1) Install Windows (tried XP and 7) in qemu (tried qemu without kvm and qemu-kvm). 2) Get OllyDbg ( http://ollydbg.de/odbg200.zip ). 3) Use some Metasploit-encoded file, example included. It is not a virus! File was generated with Metasploit, command (if i remember it right): `msfpayload windows/exec cmd=notepad R | msfencode -e x86/shikata_ga_nai -t exe -o cmd_exec_notepad.shikata_ga_nai.exe`. 4) Launch the file under Windows in qemu, make sure it opens a notepad. 5) Open file under OllyDbg, run (F9) it there. It opens a notpad. Close OllyDbg. 6) Open file under OllyDbg, trace over (Ctrl+F12) it there. It fails with `Access violation when writing to [some address]`. Command: 316A 13, XOR DWORD PTR DS:[EDX+13],EBP Under native Windows, the trace over command works fine. Under VMware the trace works fine. Under VirtualBox it also fails (checked in the spring). $ qemu-kvm --version QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 Fabrice Bellard To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/661696/+subscriptions
[Bug 1191326] Re: QNX 4 doesn't boot on qemu >= 1.3
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** Changed in: qemu Status: Confirmed => 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/1191326 Title: QNX 4 doesn't boot on qemu >= 1.3 Status in QEMU: Incomplete Bug description: I am using virtual machine with QNX4 operating system installed on it. I updated my qemu from version to newer and QNX4 doesn't start any more. All is ok on version 1.2 but when I try to use any newer version (1.3, 1.4, 1.5) QNX4 doesn't boot. I tried on windows and linux ubuntu hosts - effects are the same. When virtual machine boots qnx bootloader loads and starts operating system. In the next step qnx starts its ide driver, which detects qemu harddisk and cdrom. Problem starts when operating system tries mount partition - an error occur and qnx stop booting procedure: mount -p "No bios signature in partition sector on /dev/hd0" I have tried install qnx from cdrom but it seems that there is the same problem. QNX installer boot from cdrom, detects hard disk and cdrom, but cdrom can't be mounted in the next step of installation procedure. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1191326/+subscriptions
Re: [PATCH-for-6.0] net: tap: fix crash on hotplug
On Thu, 22 Apr 2021 at 05:29, Bin Meng wrote:
>
> On Thu, Apr 22, 2021 at 12:36 AM Philippe Mathieu-Daudé
> wrote:
> >
> > Cc'ing Bin.
> >
> > On 4/21/21 5:22 PM, Cole Robinson wrote:
> > > Attempting to hotplug a tap nic with libvirt will crash qemu:
> > >
> > > $ sudo virsh attach-interface f32 network default
> > > error: Failed to attach interface
> > > error: Unable to read from monitor: Connection reset by peer
> > >
> > > 0x55875b7f3a99 in tap_send (opaque=0x55875e39eae0) at ../net/tap.c:206
> > > 206 if (!s->nc.peer->do_not_pad) {
> > > gdb$ bt
> > >
> > > s->nc.peer may not be set at this point. This seems to be an
> > > expected case, as qemu_send_packet_* explicitly checks for NULL
> > > s->nc.peer later.
> > >
> > > Fix it by checking for s->nc.peer here too. Padding is applied if
> > > s->nc.peer is not set.
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1949786
> > > Fixes: 969e50b61a2
> > >
> > > Signed-off-by: Cole Robinson
> > > ---
> > > * Or should we skip padding if nc.peer is unset? I didn't dig into it
> > > * tap-win3.c and slirp.c may need a similar fix, but the slirp case
> > > didn't crash in a simple test.
> > >
> > > net/tap.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/net/tap.c b/net/tap.c
> > > index dd42ac6134..937559dbb8 100644
> > > --- a/net/tap.c
> > > +++ b/net/tap.c
> > > @@ -203,7 +203,7 @@ static void tap_send(void *opaque)
> > > size -= s->host_vnet_hdr_len;
> > > }
> > >
> > > -if (!s->nc.peer->do_not_pad) {
> > > +if (!s->nc.peer || !s->nc.peer->do_not_pad) {
>
> I think we should do:
>
> if (s->nc.peer && !s->nc.peer->do_not_pad)
Yes. If there is no peer then the qemu_send_packet() that we're about
to do is going to discard the packet anyway, so there's no point in
padding it.
Maybe consider
static inline bool net_peer_needs_padding(NetClientState *nc)
{
return nc->peer && !nc->peer->do_not_pad;
}
since we want the same check in three places ?
thanks
-- PMM
[Bug 612452] Re: Problems with the number of serial ports for more than two
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** Changed in: qemu Status: Confirmed => 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/612452 Title: Problems with the number of serial ports for more than two Status in QEMU: Incomplete Bug description: qemu --version QEMU emulator version 0.13.50, Copyright (c) 2003-2008 Fabrice Bellard Command line: qemu -serial null -serial null -serial file:test1 hd.img Error: isa irq 4 already assigned echo $? 1 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/612452/+subscriptions
[Bug 1854204] Re: Menu is not clickable on OSX Catalina
Still a bug. ** Changed in: qemu Status: Incomplete => 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/1854204 Title: Menu is not clickable on OSX Catalina Status in QEMU: Confirmed Bug description: 1) Run `qemu-system-x86_64` 2) Try to click on the main menu Menu is not clickable until another window is activated and QEMU window is activated again To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1854204/+subscriptions
Re: [PATCH v6] qapi: introduce 'query-cpu-model-cpuid' action
Eduardo Habkost writes:
> On Wed, Apr 21, 2021 at 08:39:42PM +0300, Valeriy Vdovin wrote:
>> On Tue, Apr 20, 2021 at 01:09:00PM -0400, Eduardo Habkost wrote:
>> > On Tue, Apr 20, 2021 at 07:19:40PM +0300, Valeriy Vdovin wrote:
>> > [...]
>> > > +##
>> > > +# @query-cpu-model-cpuid:
>> > > +#
>> > > +# Returns description of a virtual CPU model, created by QEMU after cpu
>> > > +# initialization routines. The resulting information is a reflection of
>> > > a parsed
>> > > +# '-cpu' command line option, filtered by available host cpu features.
>> > > +#
>> > > +# Returns: @CpuModelCpuidDescription
>> > > +#
>> > > +# Example:
>> > > +#
>> > > +# -> { "execute": "query-cpu-model-cpuid" }
>> > > +# <- { "return": 'CpuModelCpuidDescription' }
>> > > +#
>> > > +# Since: 6.1
>> > > +##
>> > > +{ 'command': 'query-cpu-model-cpuid',
>> > > + 'returns': 'CpuModelCpuidDescription',
>> > > + 'if': 'defined(TARGET_I386)' }
>> >
>> > I was assuming the command was going to get a CPU model name as
>> > argument.
>> >
>> > If you are only going to return info on the current CPUs, the
>> > interface could be simplified a lot.
>> >
>> > What about a simple `query-cpuid` command that only takes:
>> >
>> > { 'qom-path': 'str', # qom-path is returned by query-cpus-fast
>> >'eax': 'uint32',
>> >'*ecx': 'uint32' }
>> >
>> > as argument, and returns
>> >
>> > { 'present': 'bool',
>> >'max_eax': 'uint32',# max value of EAX for this range
>> >'*max_ecx': 'uint32', # max value of ECX if there are subleaves
>> >'eax': 'uint32',
>> >'ebx': 'uint32',
>> >'ecx': 'uint32',
>> >'edx': 'uint32' }
>> >
>> > ?
>> Hi. The interface that you suggest looks good. But it has one critical
>> point that deems it unusable for our initial needs. The point of this
>> whole new API is to take away the strain of knowing about leaf ranges
>> from the caller of this API. In my current patch this goal works. So
>> the caller does not need to know in advance what ranges there are in
>> original CPUID as well as in it's tweaked QEMU's version.
>>
>
> Raw CPUID data is a pretty low level interface, already. Is it
> really too much of a burden for callers to know that CPUID ranges
> start at 0, 0x4000, 0x8000, and 0xC000?
>
> (Especially considering that it would save us ~100 extra lines of
> C code and maybe 50-100 extra lines of QAPI schema code.)
>
>
>> But you suggested API is not so kind to the caller, so he would need
>> to add some logic around the call that knows about exact leaf ranges.
>> If you have a solution to that also, I'll be happy to discuss it.
>
> Would be following (Python-like pseudocode) be too much of a
> burden for consumers of the command?
>
> for start in (0, 0x4000, 0x8000, 0xC000):
> leaf = query_cpuid(qom_path, start)
> for eax in range(start, leaf.max_eax + 1):
> for ecx in range(0, leaf.get('max_ecx', 0) + 1):
> all_leaves.append(query_cpuid(qom_path, eax, ecx))
>
>>
>> The obvious thing that comes to mind is changing the exists/max_ecx pair
>> to something like next_eax, next_ecx. But this idea will probably require
>> the same amount of complexity that I currently have in this patch.
>
> I agree. I'm trying to reduce the complexity of the interface
> and of the command implementation.
This command appears to be primarily motivated by a container use case
that doesn't involve QEMU (other than as a provider of a language to
construct CPU models)[1]. It has secondary applications that do involve
QEMU, but they seem quite limited (automated tests[2], debugging).
This is rather weak justification for QMP command. It may suffice for a
really simple patch along the lines Eduardo proposed. Any additional
complexity would be a hard sell, though.
[1] Message-ID: <20210329112153.ga413...@dhcp-172-16-24-191.sw.ru>
https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg09463.html
[2] Message-ID: <20210419202336.shf3yo7lmr7tm...@habkost.net>
https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg03697.html
[PATCH] i386/cpu: Remove the deprecated cpu model 'Icelake-Client'
As it's been marked deprecated since v5.2, now I think it's time remove it
from code.
Signed-off-by: Robert Hoo
---
target/i386/cpu.c | 118 --
1 file changed, 118 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index ad99cad..75f2ad1 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -3338,124 +3338,6 @@ static X86CPUDefinition builtin_x86_defs[] = {
.model_id = "Intel Xeon Processor (Cooperlake)",
},
{
-.name = "Icelake-Client",
-.level = 0xd,
-.vendor = CPUID_VENDOR_INTEL,
-.family = 6,
-.model = 126,
-.stepping = 0,
-.features[FEAT_1_EDX] =
-CPUID_VME | CPUID_SSE2 | CPUID_SSE | CPUID_FXSR | CPUID_MMX |
-CPUID_CLFLUSH | CPUID_PSE36 | CPUID_PAT | CPUID_CMOV | CPUID_MCA |
-CPUID_PGE | CPUID_MTRR | CPUID_SEP | CPUID_APIC | CPUID_CX8 |
-CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
-CPUID_DE | CPUID_FP87,
-.features[FEAT_1_ECX] =
-CPUID_EXT_AVX | CPUID_EXT_XSAVE | CPUID_EXT_AES |
-CPUID_EXT_POPCNT | CPUID_EXT_X2APIC | CPUID_EXT_SSE42 |
-CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
-CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3 |
-CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_FMA | CPUID_EXT_MOVBE |
-CPUID_EXT_PCID | CPUID_EXT_F16C | CPUID_EXT_RDRAND,
-.features[FEAT_8000_0001_EDX] =
-CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX |
-CPUID_EXT2_SYSCALL,
-.features[FEAT_8000_0001_ECX] =
-CPUID_EXT3_ABM | CPUID_EXT3_LAHF_LM | CPUID_EXT3_3DNOWPREFETCH,
-.features[FEAT_8000_0008_EBX] =
-CPUID_8000_0008_EBX_WBNOINVD,
-.features[FEAT_7_0_EBX] =
-CPUID_7_0_EBX_FSGSBASE | CPUID_7_0_EBX_BMI1 |
-CPUID_7_0_EBX_HLE | CPUID_7_0_EBX_AVX2 | CPUID_7_0_EBX_SMEP |
-CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_ERMS | CPUID_7_0_EBX_INVPCID |
-CPUID_7_0_EBX_RTM | CPUID_7_0_EBX_RDSEED | CPUID_7_0_EBX_ADX |
-CPUID_7_0_EBX_SMAP,
-.features[FEAT_7_0_ECX] =
-CPUID_7_0_ECX_AVX512_VBMI | CPUID_7_0_ECX_UMIP | CPUID_7_0_ECX_PKU
|
-CPUID_7_0_ECX_AVX512_VBMI2 | CPUID_7_0_ECX_GFNI |
-CPUID_7_0_ECX_VAES | CPUID_7_0_ECX_VPCLMULQDQ |
-CPUID_7_0_ECX_AVX512VNNI | CPUID_7_0_ECX_AVX512BITALG |
-CPUID_7_0_ECX_AVX512_VPOPCNTDQ,
-.features[FEAT_7_0_EDX] =
-CPUID_7_0_EDX_SPEC_CTRL | CPUID_7_0_EDX_SPEC_CTRL_SSBD,
-/* Missing: XSAVES (not supported by some Linux versions,
-* including v4.1 to v4.12).
-* KVM doesn't yet expose any XSAVES state save component,
-* and the only one defined in Skylake (processor tracing)
-* probably will block migration anyway.
-*/
-.features[FEAT_XSAVE] =
-CPUID_XSAVE_XSAVEOPT | CPUID_XSAVE_XSAVEC |
-CPUID_XSAVE_XGETBV1,
-.features[FEAT_6_EAX] =
-CPUID_6_EAX_ARAT,
-/* Missing: Mode-based execute control (XS/XU), processor tracing, TSC
scaling */
-.features[FEAT_VMX_BASIC] = MSR_VMX_BASIC_INS_OUTS |
- MSR_VMX_BASIC_TRUE_CTLS,
-.features[FEAT_VMX_ENTRY_CTLS] = VMX_VM_ENTRY_IA32E_MODE |
- VMX_VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL |
VMX_VM_ENTRY_LOAD_IA32_PAT |
- VMX_VM_ENTRY_LOAD_DEBUG_CONTROLS | VMX_VM_ENTRY_LOAD_IA32_EFER,
-.features[FEAT_VMX_EPT_VPID_CAPS] = MSR_VMX_EPT_EXECONLY |
- MSR_VMX_EPT_PAGE_WALK_LENGTH_4 | MSR_VMX_EPT_WB | MSR_VMX_EPT_2MB
|
- MSR_VMX_EPT_1GB | MSR_VMX_EPT_INVEPT |
- MSR_VMX_EPT_INVEPT_SINGLE_CONTEXT |
MSR_VMX_EPT_INVEPT_ALL_CONTEXT |
- MSR_VMX_EPT_INVVPID | MSR_VMX_EPT_INVVPID_SINGLE_ADDR |
- MSR_VMX_EPT_INVVPID_SINGLE_CONTEXT |
MSR_VMX_EPT_INVVPID_ALL_CONTEXT |
- MSR_VMX_EPT_INVVPID_SINGLE_CONTEXT_NOGLOBALS |
MSR_VMX_EPT_AD_BITS,
-.features[FEAT_VMX_EXIT_CTLS] =
- VMX_VM_EXIT_ACK_INTR_ON_EXIT | VMX_VM_EXIT_SAVE_DEBUG_CONTROLS |
- VMX_VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL |
- VMX_VM_EXIT_LOAD_IA32_PAT | VMX_VM_EXIT_LOAD_IA32_EFER |
- VMX_VM_EXIT_SAVE_IA32_PAT | VMX_VM_EXIT_SAVE_IA32_EFER |
- VMX_VM_EXIT_SAVE_VMX_PREEMPTION_TIMER,
-.features[FEAT_VMX_MISC] = MSR_VMX_MISC_ACTIVITY_HLT |
- MSR_VMX_MISC_STORE_LMA | MSR_VMX_MISC_VMWRITE_VMEXIT,
-.features[FEAT_VMX_PINBASED_CTLS] = VMX_PIN_BASED_EXT_INTR_MASK |
- VMX_PIN_BASED_NMI_EXITING | VMX_PIN_BASED_VIRTUAL_NMIS |
- VMX_PIN_BASED_VMX_PREEMPTION_TIMER,
-.features[FEAT_VMX_PROCBASED_CTLS] =
VMX_CPU_BASED_VIRTUAL_INTR_PENDING |
- VMX_CPU_BASED_USE_TSC_OFFSETING | VMX_CPU_BASED_HLT_EXITING |
- VMX_CPU_BASED_INVLPG
Re: [PATCH-for-6.0] net: tap: fix crash on hotplug
On Thu, Apr 22, 2021 at 5:36 PM Peter Maydell wrote:
>
> On Thu, 22 Apr 2021 at 05:29, Bin Meng wrote:
> >
> > On Thu, Apr 22, 2021 at 12:36 AM Philippe Mathieu-Daudé
> > wrote:
> > >
> > > Cc'ing Bin.
> > >
> > > On 4/21/21 5:22 PM, Cole Robinson wrote:
> > > > Attempting to hotplug a tap nic with libvirt will crash qemu:
> > > >
> > > > $ sudo virsh attach-interface f32 network default
> > > > error: Failed to attach interface
> > > > error: Unable to read from monitor: Connection reset by peer
> > > >
> > > > 0x55875b7f3a99 in tap_send (opaque=0x55875e39eae0) at
> > > > ../net/tap.c:206
> > > > 206 if (!s->nc.peer->do_not_pad) {
> > > > gdb$ bt
> > > >
> > > > s->nc.peer may not be set at this point. This seems to be an
> > > > expected case, as qemu_send_packet_* explicitly checks for NULL
> > > > s->nc.peer later.
> > > >
> > > > Fix it by checking for s->nc.peer here too. Padding is applied if
> > > > s->nc.peer is not set.
> > > >
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1949786
> > > > Fixes: 969e50b61a2
> > > >
> > > > Signed-off-by: Cole Robinson
> > > > ---
> > > > * Or should we skip padding if nc.peer is unset? I didn't dig into it
> > > > * tap-win3.c and slirp.c may need a similar fix, but the slirp case
> > > > didn't crash in a simple test.
> > > >
> > > > net/tap.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/net/tap.c b/net/tap.c
> > > > index dd42ac6134..937559dbb8 100644
> > > > --- a/net/tap.c
> > > > +++ b/net/tap.c
> > > > @@ -203,7 +203,7 @@ static void tap_send(void *opaque)
> > > > size -= s->host_vnet_hdr_len;
> > > > }
> > > >
> > > > -if (!s->nc.peer->do_not_pad) {
> > > > +if (!s->nc.peer || !s->nc.peer->do_not_pad) {
> >
> > I think we should do:
> >
> > if (s->nc.peer && !s->nc.peer->do_not_pad)
>
> Yes. If there is no peer then the qemu_send_packet() that we're about
> to do is going to discard the packet anyway, so there's no point in
> padding it.
>
> Maybe consider
>
> static inline bool net_peer_needs_padding(NetClientState *nc)
> {
> return nc->peer && !nc->peer->do_not_pad;
> }
>
> since we want the same check in three places ?
Sounds good to me.
Regards,
Bin
[Bug 1574346] Re: TCG: mov to segment register is incorrectly emulated for AMD CPUs
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** Changed in: qemu Status: Confirmed => 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/1574346 Title: TCG: mov to segment register is incorrectly emulated for AMD CPUs Status in QEMU: Incomplete Bug description: In TCG mode, the effect of: xorl %eax, %eax movl %eax, %gs is to mark the GS segment unusable and set its base to zero. After doing this, reading MSR_GS_BASE will return zero and using a GS prefix in long mode will treat the GS base as zero. This is correct for Intel CPUs but is incorrect for AMD CPUs. On an AMD CPU, writing 0 to %gs using mov, pop, or (I think) lgs will leave the base unchanged. To make it easier to use TCG to validate behavior on different CPUs, please consider changing the TCG behavior to match actual CPU behavior when emulating an AMD CPU. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1574346/+subscriptions
[Bug 1614609] Re: alphabetical order of monitor options
Fix has been included here: https://gitlab.com/qemu-project/qemu/-/commit/ff688cd2c7c3a677b71e ** Changed in: qemu Status: In Progress => 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/1614609 Title: alphabetical order of monitor options Status in QEMU: Fix Committed Bug description: Looking for the 'continue'/'resume' option I found this order that was not quite 'alphabetical'. It had me overlook the 'cont' option at glance. Which is just a little impractical. ... boot_set bootdevice -- define new values for the boot device list change device filename [format [read-only-mode]] -- change a removable medium, optional format chardev-add args -- add chardev chardev-remove id -- remove chardev client_migrate_info protocol hostname port tls-port cert-subject -- set migration information for remote display closefd closefd name -- close a file descriptor previously passed via SCM rights commit device|all -- commit changes to the disk images (if -snapshot is used) or backing files cpu index -- set the default CPU cpu-add id -- add cpu c|cont -- resume emulation delvm tag|id -- delete a VM snapshot from its tag or id ... I tested this list with 'sort' just to make sure and make a point: $ cat Desktop/order-orig.txt boot_set change chardev-add chardev-remove client_migrate_info closefd commit cpu cpu-add c|cont delvm $ cat Desktop/order-orig.txt | sort boot_set c|cont change chardev-add chardev-remove client_migrate_info closefd commit cpu cpu-add delvm $ To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1614609/+subscriptions
[Bug 661696] Re: incomplete emulation of fstenv under TCG
Test case in comment #7 still fails -- still a bug. ** Changed in: qemu Status: Incomplete => 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/661696 Title: incomplete emulation of fstenv under TCG Status in QEMU: Confirmed Bug description: Steps to reproduce: 1) Install Windows (tried XP and 7) in qemu (tried qemu without kvm and qemu-kvm). 2) Get OllyDbg ( http://ollydbg.de/odbg200.zip ). 3) Use some Metasploit-encoded file, example included. It is not a virus! File was generated with Metasploit, command (if i remember it right): `msfpayload windows/exec cmd=notepad R | msfencode -e x86/shikata_ga_nai -t exe -o cmd_exec_notepad.shikata_ga_nai.exe`. 4) Launch the file under Windows in qemu, make sure it opens a notepad. 5) Open file under OllyDbg, run (F9) it there. It opens a notpad. Close OllyDbg. 6) Open file under OllyDbg, trace over (Ctrl+F12) it there. It fails with `Access violation when writing to [some address]`. Command: 316A 13, XOR DWORD PTR DS:[EDX+13],EBP Under native Windows, the trace over command works fine. Under VMware the trace works fine. Under VirtualBox it also fails (checked in the spring). $ qemu-kvm --version QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 Fabrice Bellard To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/661696/+subscriptions
Re: [PATCH] block: simplify write-threshold and drop write notifiers
On 22/04/2021 00:09, Vladimir Sementsov-Ogievskiy wrote:
write-notifiers are used only for write-threshold. New code for such
purpose should create filters.
Let's handle write-threshold simply in generic code and drop write
notifiers at all.
Also move part of write-threshold API that is used only for testing to
the test.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
I agree that this could be split into 2-3 parts and not combining
everything into one. But I'm tired now. I can send v2 if needed, so
consider it as RFC. Or take as is if you think it's not too much-in-one.
Thank you for this patch. Since I am reworking on v2, if you want I can
also integrate this patch with mines and send everything together once I
am done.
Emanuele
I also suggest this as a prepartion (and partly substitution) for
"[PATCH v2 0/8] Block layer thread-safety, continued"
include/block/block_int.h | 12 -
include/block/write-threshold.h | 24 -
block.c | 1 -
block/io.c| 21 +---
block/write-threshold.c | 87 ++-
tests/unit/test-write-threshold.c | 38 ++
6 files changed, 54 insertions(+), 129 deletions(-)
diff --git a/include/block/block_int.h b/include/block/block_int.h
index 88e4111939..50af58af75 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -957,12 +957,8 @@ struct BlockDriverState {
*/
int64_t total_sectors;
-/* Callback before write request is processed */
-NotifierWithReturnList before_write_notifiers;
-
/* threshold limit for writes, in bytes. "High water mark". */
uint64_t write_threshold_offset;
-NotifierWithReturn write_threshold_notifier;
/* Writing to the list requires the BQL _and_ the dirty_bitmap_mutex.
* Reading from the list can be done with either the BQL or the
@@ -1087,14 +1083,6 @@ void bdrv_parse_filename_strip_prefix(const char
*filename, const char *prefix,
bool bdrv_backing_overridden(BlockDriverState *bs);
-/**
- * bdrv_add_before_write_notifier:
- *
- * Register a callback that is invoked before write requests are processed but
- * after any throttling or waiting for overlapping requests.
- */
-void bdrv_add_before_write_notifier(BlockDriverState *bs,
-NotifierWithReturn *notifier);
/**
* bdrv_add_aio_context_notifier:
diff --git a/include/block/write-threshold.h b/include/block/write-threshold.h
index c646f267a4..23e1bfc123 100644
--- a/include/block/write-threshold.h
+++ b/include/block/write-threshold.h
@@ -35,28 +35,4 @@ void bdrv_write_threshold_set(BlockDriverState *bs, uint64_t
threshold_bytes);
*/
uint64_t bdrv_write_threshold_get(const BlockDriverState *bs);
-/*
- * bdrv_write_threshold_is_set
- *
- * Tell if a write threshold is set for a given BDS.
- */
-bool bdrv_write_threshold_is_set(const BlockDriverState *bs);
-
-/*
- * bdrv_write_threshold_exceeded
- *
- * Return the extent of a write request that exceeded the threshold,
- * or zero if the request is below the threshold.
- * Return zero also if the threshold was not set.
- *
- * NOTE: here we assume the following holds for each request this code
- * deals with:
- *
- * assert((req->offset + req->bytes) <= UINT64_MAX)
- *
- * Please not there is *not* an actual C assert().
- */
-uint64_t bdrv_write_threshold_exceeded(const BlockDriverState *bs,
- const BdrvTrackedRequest *req);
-
#endif
diff --git a/block.c b/block.c
index c5b887cec1..001453105e 100644
--- a/block.c
+++ b/block.c
@@ -381,7 +381,6 @@ BlockDriverState *bdrv_new(void)
for (i = 0; i < BLOCK_OP_TYPE_MAX; i++) {
QLIST_INIT(&bs->op_blockers[i]);
}
-notifier_with_return_list_init(&bs->before_write_notifiers);
qemu_co_mutex_init(&bs->reqs_lock);
qemu_mutex_init(&bs->dirty_bitmap_mutex);
bs->refcnt = 1;
diff --git a/block/io.c b/block/io.c
index ca2dca3007..e0aa775952 100644
--- a/block/io.c
+++ b/block/io.c
@@ -36,6 +36,8 @@
#include "qemu/main-loop.h"
#include "sysemu/replay.h"
+#include "qapi/qapi-events-block-core.h"
+
/* Maximum bounce buffer for copy-on-read and write zeroes, in bytes */
#define MAX_BOUNCE_BUFFER (32768 << BDRV_SECTOR_BITS)
@@ -1974,6 +1976,8 @@ bdrv_co_write_req_prepare(BdrvChild *child, int64_t offset, int64_t bytes,
child->perm & BLK_PERM_RESIZE);
switch (req->type) {
+uint64_t write_threshold;
+
case BDRV_TRACKED_WRITE:
case BDRV_TRACKED_DISCARD:
if (flags & BDRV_REQ_WRITE_UNCHANGED) {
@@ -1981,8 +1985,15 @@ bdrv_co_write_req_prepare(BdrvChild *child, int64_t
offset, int64_t bytes,
} else {
assert(child->perm & BLK_PERM_WRITE);
}
-return notifier_with_return_list_notify(&bs->before_write_notifiers,
-req);
+
Re: [PATCH v3 01/27] target: Set CPUClass::vmsd instead of DeviceClass::vmsd
+Juan
On 4/22/21 12:03 AM, Eduardo Habkost wrote:
> On Tue, Mar 02, 2021 at 03:57:52PM +0100, Philippe Mathieu-Daudé wrote:
>> The cpu model is the single device available in user-mode.
>> Since we want to restrict some fields to user-mode emulation,
>> we prefer to set the vmsd field of CPUClass, rather than the
>> DeviceClass one.
>>
>> Signed-off-by: Philippe Mathieu-Daudé
>
> Is this going to have an externally visible effect?
On system emulation, no, because unchanged.
On user emulation migration it is not used, the symbol is here
to satisfy linking:
include/hw/core/cpu.h-1070-#ifdef CONFIG_SOFTMMU
include/hw/core/cpu.h-1071-extern const VMStateDescription
vmstate_cpu_common;
include/hw/core/cpu.h-1072-#else
include/hw/core/cpu.h:1073:#define vmstate_cpu_common vmstate_dummy
include/hw/core/cpu.h-1074-#endif
include/migration/vmstate.h:197:extern const VMStateDescription
vmstate_dummy;
stubs/vmstate.c:4:const VMStateDescription vmstate_dummy = {};
> If it does, how can we make sure it's safe?
>
> If it does not, do you know why CPUClass::vmsd exists in the
> first place?
My guess is CPUState is the only device used in user emulation,
so it would be a way to restrict the vmstate_dummy to CPU and
not to any DeviceState?
But looking at the introductory commit:
commit b170fce3dd06372f7bfec9a780ebcb1fce6d57e4
Author: Andreas Färber
Date: Sun Jan 20 20:23:22 2013 +0100
cpu: Register VMStateDescription through CPUState
In comparison to DeviceClass::vmsd, CPU VMState is split in two,
"cpu_common" and "cpu", and uses cpu_index as instance_id instead of -1.
Therefore add a CPU-specific CPUClass::vmsd field.
Unlike the legacy CPUArchState registration, rather register CPUState.
Juan, do you remember?
>
> Do you think it would be simpler to just squash this patch into
> [PATCH v3 08/27] cpu: Move CPUClass::vmsd to SysemuCPUOps
> ?
Certainly cleaner, I'll respin!
Thanks,
Phil.
[Bug 1847467] Re: qemu-x86_64 segment prefixes error
Repro case in comment #1 still demonstrates bug. ** Changed in: qemu Status: Incomplete => 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/1847467 Title: qemu-x86_64 segment prefixes error Status in QEMU: Confirmed Bug description: qemu-x86_64 version 4.1.0 (qemu-x86_64 version 4.0.0 also have the issue) In 64-bit mode (x86_64) the DS, ES, SS or CS segment prefixes should be ignored; qemu-x86_64 does not ignore them. example: an x86_64 instructions preceded by FS DS (0x64 0x26) segment prefixes have the linear address of its memory reference flat-mapped (as if DS was in action) whereas it should be FS-mapped (offset by FS_base, because the DS, ES, SS or CS are just ignored). I attach a small C++ program that shows this discrepancy. $ ./sample I'm not in QEMU $ qemu-x86_64 ./sample I'm in QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1847467/+subscriptions
Re: [PATCH] block: simplify write-threshold and drop write notifiers
22.04.2021 12:57, Emanuele Giuseppe Esposito wrote: On 22/04/2021 00:09, Vladimir Sementsov-Ogievskiy wrote: write-notifiers are used only for write-threshold. New code for such purpose should create filters. Let's handle write-threshold simply in generic code and drop write notifiers at all. Also move part of write-threshold API that is used only for testing to the test. Signed-off-by: Vladimir Sementsov-Ogievskiy --- I agree that this could be split into 2-3 parts and not combining everything into one. But I'm tired now. I can send v2 if needed, so consider it as RFC. Or take as is if you think it's not too much-in-one. Thank you for this patch. Since I am reworking on v2, if you want I can also integrate this patch with mines and send everything together once I am done. Emanuele I'd wait several days for comments. Maybe I'll have to resend v2 of this. Also, after this patch, is something of your patches 1-4 needed? Probably you may just resend your series not touching write-threshold, and just note in cover-letter that write-threshold is covered by "[PATCH] block: simplify write-threshold and drop write notifiers" -- Best regards, Vladimir
[Bug 1580459] Re: Windows (10?) guest freezes entire host on shutdown if using PCI passthrough
I am no longer having any issues at all. I am using the NVidia Sound Card as well. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1580459 Title: Windows (10?) guest freezes entire host on shutdown if using PCI passthrough Status in libvirt: New Status in QEMU: Incomplete Status in Arch Linux: New Status in Debian: New Status in Fedora: New Bug description: Problem: after leaving a Windows VM that uses PCI passthrough (as we do for gaming graphics cards, sound cards, and in my case, a USB card) running for some amount of time between 1 and 2 hours (it's not consistent with exactly how long), and for any amount of time longer than that, shutting down that guest will, right as it finishes shutting down, freeze the host computer, making it require a hard reboot. Unbinding (or in the other user's case, unbinding and THEN binding) any PCI device in sysfs, even one that has nothing to do with the VM, also has the same effect as shutting down the VM (if the VM has been running long enough). So, it's probably an issue related to unbinding and binding PCI devices. There's a lot of info on this problem over at https://bbs.archlinux.org/viewtopic.php?id=206050 Here's a better-organized list of main details: -at least 2 confirmed victims of this bug; 2 (including me) have provided lots of info in the link -I'm on Arch Linux and the other one is on Gentoo (distro-nonspecific) -issue affects my Windows 10 guest and others' Windows guests, but not my Arch Linux guest (the others don't have non-Windows guests to test) -I'm using libvirt but the other user is not, so it's not an issue with libvirt -It seems to be version non-specific, too. I first noticed it at, or when testing versions still had the issue at (whichever version is lower), Linux 4.1 and qemu 2.4.0. It still persists in all releases of both since, including the newest ones. -I can't track down exactly what package downgrade can fix it, as downgrading further than Linux 4.1 and qemu 2.4.0 requires Herculean and system-destroying changes such as downgrading ncurses, meaning I don't know whether it's a bug in QEMU, the Linux kernel, or some weird seemingly unrelated thing. -According to the other user, "graphics intensive gameplay (GTA V) can cause the crash to happen sooner," as soon as "15 minutes" -Also, "bringing up a second passthrough VM with separate hardware will cause the same crash," and "bringing up another VM before the two-hour mark will not result in a crash," further cementing that it's triggered by the un/binding of PCI devices. -This is NOT related to the very similar bug that can be worked around by not passing through the HDMI device or sound card. Even when we removed all traces of any sort of sound card from the VM, it still had the same behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/libvirt/+bug/1580459/+subscriptions
[Bug 1534978] Re: Windows command line -name cannot use = sign
Thanks for checking! Closing now. ** Changed in: qemu Status: Incomplete => 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/1534978 Title: Windows command line -name cannot use = sign Status in QEMU: Fix Released Bug description: Windows command line: qemu.exe -L . -name "32-bit Emulation Session RAM=500MB" -boot c -m 500 -drive file=\\.\PhysicalDrive2 This fails to run. If I remove the = sign in the -name quoted string it runs OK. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1534978/+subscriptions
Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
On Thu, Apr 22, 2021 at 06:47:30AM +0200, Thomas Huth wrote: > On 22/04/2021 06.18, Philippe Mathieu-Daudé wrote: > > Hi Thomas, Daniel, Stefano, > > > > Regarding the following warning (GCC 11 on Fedora 34): > > > > In file included from pc-bios/s390-ccw/main.c:11: > > > > In function ‘memset’, > > > > inlined from ‘boot_setup’ at pc-bios/s390-ccw/main.c:185:5, > > > > inlined from ‘main’ at pc-bios/s390-ccw/main.c:288:5: > > > > pc-bios/s390-ccw/libc.h:28:14: warning: writing 1 byte into a region of > > size 0 [-Wstringop-overflow=] > > > > 28 | p[i] = c; > > > >| ~^~~ > > > > Daniel were right on IRC: > > > > danpb: it is from a call memset((char *)S390EP, 0, 6) where S390EP > > is just a constant address 0x10008 > > danpb: the compiler doesn't now how big that is, so it seems to assume > > it is zero length > > > > This is a known GCC issue: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 > > "gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a > > pointer from integer literal" > > Hi Philippe, > > thanks for following up with the gcc bugzilla! > > ... so the problem is that GCC thinks we're in fact dereferencing a NULL > pointer at offset 0x10008 here? Wow, that's ... crazy. > > Not sure what to do now - wait for the bug to get resolved? Compile the > s390-ccw bios with -Wno-stringop-overread ? Add "volatiles" here and there > to hope that these silence the compiler warnings? ... I tend to wait for the > bug ticket to see whether the GCC folks change the behavior of the compiler > again, but I'm open for other suggestions. Assuming it is just this one place in the code ,then we should just use "pragma" to temporarily disable/re-enable that single warning flag either side of the problem. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
[Bug 1835865] Re: piix crashes on mips when accessing acpi-pci-hotplug
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** Changed in: qemu Status: Confirmed => 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/1835865 Title: piix crashes on mips when accessing acpi-pci-hotplug Status in QEMU: Incomplete Bug description: $ qemu-system-mips --version QEMU emulator version 4.0.50 (v4.0.0-1975-gf34edbc760) $ qemu-system-mips -machine malta -bios /dev/null -nodefaults -monitor stdio -S (qemu) o 0xaf00 0 qemu-system-mips: hw/acpi/cpu.c:197: cpu_hotplug_hw_init: Assertion `mc->possible_cpu_arch_ids' failed. Aborted (core dumped) (gdb) bt #0 0x7f6fd748957f in raise () at /lib64/libc.so.6 #1 0x7f6fd7473895 in abort () at /lib64/libc.so.6 #2 0x7f6fd7473769 in _nl_load_domain.cold.0 () at /lib64/libc.so.6 #3 0x7f6fd7481a26 in .annobin_assert.c_end () at /lib64/libc.so.6 #4 0x5646d58ca7bd in cpu_hotplug_hw_init (as=0x5646d6ae3300, owner=0x5646d6fd5b10, state=0x5646d6fd7a30, base_addr=44800) at hw/acpi/cpu.c:197 #5 0x5646d58c5284 in acpi_switch_to_modern_cphp (gpe_cpu=0x5646d6fd7910, cpuhp_state=0x5646d6fd7a30, io_port=44800) at hw/acpi/cpu_hotplug.c:107 #6 0x5646d58c3431 in piix4_set_cpu_hotplug_legacy (obj=0x5646d6fd5b10, value=false, errp=0x5646d61cdb28 ) at hw/acpi/piix4.c:617 #7 0x5646d5b00c70 in property_set_bool (obj=0x5646d6fd5b10, v=0x5646d7697d30, name=0x5646d5cf3a90 "cpu-hotplug-legacy", opaque=0x5646d707d110, errp=0x5646d61cdb28 ) at qom/object.c:2076 #8 0x5646d5afeee6 in object_property_set (obj=0x5646d6fd5b10, v=0x5646d7697d30, name=0x5646d5cf3a90 "cpu-hotplug-legacy", errp=0x5646d61cdb28 ) at qom/object.c:1268 #9 0x5646d5b01fb8 in object_property_set_qobject (obj=0x5646d6fd5b10, value=0x5646d75b5450, name=0x5646d5cf3a90 "cpu-hotplug-legacy", errp=0x5646d61cdb28 ) at qom/qom-qobject.c:26 #10 0x5646d5aff1cb in object_property_set_bool (obj=0x5646d6fd5b10, value=false, name=0x5646d5cf3a90 "cpu-hotplug-legacy", errp=0x5646d61cdb28 ) at qom/object.c:1334 #11 0x5646d58c4fce in cpu_status_write (opaque=0x5646d6fd7910, addr=0, data=0, size=1) at hw/acpi/cpu_hotplug.c:44 #12 0x5646d569c707 in memory_region_write_accessor (mr=0x5646d6fd7920, addr=0, value=0x7ffc18053068, size=1, shift=0, mask=255, attrs=...) at memory.c:503 #13 0x5646d569c917 in access_with_adjusted_size (addr=0, value=0x7ffc18053068, size=1, access_size_min=1, access_size_max=4, access_fn=0x5646d569c61e , mr=0x5646d6fd7920, attrs=...) at memory.c:569 #14 0x5646d569f8f3 in memory_region_dispatch_write (mr=0x5646d6fd7920, addr=0, data=0, size=1, attrs=...) at memory.c:1497 #15 0x5646d563e5c5 in flatview_write_continue (fv=0x5646d751b000, addr=44800, attrs=..., buf=0x7ffc180531d4 "", len=4, addr1=0, l=1, mr=0x5646d6fd7920) at exec.c:3324 #16 0x5646d563e70a in flatview_write (fv=0x5646d751b000, addr=44800, attrs=..., buf=0x7ffc180531d4 "", len=4) at exec.c:3363 #17 0x5646d563ea0f in address_space_write (as=0x5646d618abc0 , addr=44800, attrs=..., buf=0x7ffc180531d4 "", len=4) at exec.c:3453 #18 0x5646d5696ee5 in cpu_outl (addr=44800, val=0) at ioport.c:80 #19 0x5646d57585d0 in hmp_ioport_write (mon=0x5646d6bc70e0, qdict=0x5646d6cf7140) at monitor/misc.c:1058 #20 0x5646d5a77b99 in handle_hmp_command (mon=0x5646d6bc70e0, cmdline=0x5646d6bc2542 "0xaf00 0") at monitor/hmp.c:1082 #21 0x5646d5a7540a in monitor_command_cb (opaque=0x5646d6bc70e0, cmdline=0x5646d6bc2540 "o 0xaf00 0", readline_opaque=0x0) at monitor/hmp.c:47 #22 0x5646d5c71450 in readline_handle_byte (rs=0x5646d6bc2540, ch=13) at util/readline.c:408 #23 0x5646d5a7858f in monitor_read (opaque=0x5646d6bc70e0, buf=0x7ffc180533d0 "\rtc\327FV", size=1) at monitor/hmp.c:1312 #24 0x5646d5bc8d17 in qemu_chr_be_write_impl (s=0x5646d6add000, buf=0x7ffc180533d0 "\rtc\327FV", len=1) at chardev/char.c:177 #25 0x5646d5bc8d7b in qemu_chr_be_write (s=0x5646d6add000, buf=0x7ffc180533d0 "\rtc\327FV", len=1) at chardev/char.c:189 #26 0x5646d5bcb6bf in fd_chr_read (chan=0x5646d6a80d60, cond=G_IO_IN, opaque=0x5646d6add000) at chardev/char-fd.c:68 #27 0x5646d5bec485 in qio_channel_fd_source_dispatch (source=0x5646d765a480, callback=0x5646d5bcb561 , user_data=0x5646d6add000) at io/channel-watch.c:84 #28 0x7f6fd9c1606d in g_main_context_dispatc
[Bug 1829498] Re: window 8 stuck during boot on Qemu
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** Changed in: qemu Status: Confirmed => 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/1829498 Title: window 8 stuck during boot on Qemu Status in QEMU: Incomplete Bug description: Description of problem: I've got windows 8 image(64 bit), installed on Qemu(x86-64_softmmu) and then i'm trying to boot/shutdown it in the same Qemu configuration. Windows 8 has feature - when you click "Shutdown" in UI, windows 8 doesn't actually power off, it goes to "Suspend to disc" ACPI state. After shutdown, i'm trying to boot it again, but it stucks during boot. I've discovered, that it hangs when windows 8 writes to AHCI's command register, AHCI triggers irq, but windows 8 sends EOI, don't accessing AHCI register,so irq line stills in high state, and irq will be injected again and again, while windows will send EOI on each AHCI interrupt. Strange thing is that it happens only on TCG mode or with option "kernel-irqchip=off/split", with "kernel-irqchip=on" everything works ok(windows 8 accesses AHCI register and line goes to low state). Version-Release number of selected component (if applicable): Qemu revision: d8276573da58e8ce78dab8c46dd660efd664bcb7 Steps to Reproduce: 1. Install Windows 8 on QEMU(qemu command line: "-enable-kvm -m 1G -hda -serial stdio -cpu core2duo -machine q35,kernel-irqchip=off" 2. Click shutdown in UI. 3. Try to boot again(it will stuck) 4. Kill Qemu and boot again, it will boot, now go to 2) :) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1829498/+subscriptions
Re: [PATCH v3 01/27] target: Set CPUClass::vmsd instead of DeviceClass::vmsd
On Thu, 22 Apr 2021 at 10:55, Philippe Mathieu-Daudé wrote: > My guess is CPUState is the only device used in user emulation, > so it would be a way to restrict the vmstate_dummy to CPU and > not to any DeviceState? > > But looking at the introductory commit: > > commit b170fce3dd06372f7bfec9a780ebcb1fce6d57e4 > Author: Andreas Färber > Date: Sun Jan 20 20:23:22 2013 +0100 > > cpu: Register VMStateDescription through CPUState > > In comparison to DeviceClass::vmsd, CPU VMState is split in two, > "cpu_common" and "cpu", and uses cpu_index as instance_id instead of -1. > Therefore add a CPU-specific CPUClass::vmsd field. > > Unlike the legacy CPUArchState registration, rather register CPUState. > > Juan, do you remember? Oh yes, I remember this. There are two ways to handle migration for a CPU object: (1) like any other device, so it has a dc->vmsd that covers migration for the whole object. As usual for objects that are a subclass of a parent that has state, the first entry in the VMStateDescription field list is VMSTATE_CPU(), which migrates the cpu_common fields, followed by whatever the CPU's own migration fields are. (2) a backwards-compatible mechanism for CPUs that were originally migrated using manual "write fields to the migration stream structures". The on-the-wire migration format for those is based on the 'env' pointer (which isn't a QOM object), and the cpu_common part of the migration data is elsewhere. cpu_exec_realizefn() handles both possibilities: * for type 1, dc->vmsd is set and cc->vmsd is not, so cpu_exec_realizefn() does nothing, and the standard "register dc->vmsd for a device" code does everything needed * for type 2, dc->vmsd is NULL and so we register the vmstate_cpu_common directly to handle the cpu-common fields, and the cc->vmsd to handle the per-CPU stuff You can't change a CPU from one type to the other without breaking migration compatibility, which is why some guest architectures are stuck on the cc->vmsd form. New targets should use dc->vmsd. thanks -- PMM
Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
On Thu, 22 Apr 2021 at 11:18, Daniel P. Berrangé wrote: > > On Thu, Apr 22, 2021 at 06:47:30AM +0200, Thomas Huth wrote: > > On 22/04/2021 06.18, Philippe Mathieu-Daudé wrote: > > > Hi Thomas, Daniel, Stefano, > > > > > > Regarding the following warning (GCC 11 on Fedora 34): > > > > > > In file included from pc-bios/s390-ccw/main.c:11: > > > > > > In function ‘memset’, > > > > > > inlined from ‘boot_setup’ at pc-bios/s390-ccw/main.c:185:5, > > > > > > inlined from ‘main’ at pc-bios/s390-ccw/main.c:288:5: > > > > > > pc-bios/s390-ccw/libc.h:28:14: warning: writing 1 byte into a region of > > > size 0 [-Wstringop-overflow=] > > > > > > 28 | p[i] = c; > > > > > >| ~^~~ > > > > > > Daniel were right on IRC: > > > > > > danpb: it is from a call memset((char *)S390EP, 0, 6) where S390EP > > > is just a constant address 0x10008 > > > danpb: the compiler doesn't now how big that is, so it seems to assume > > > it is zero length > > > > > > This is a known GCC issue: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 > > > "gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a > > > pointer from integer literal" > > > > Hi Philippe, > > > > thanks for following up with the gcc bugzilla! > > > > ... so the problem is that GCC thinks we're in fact dereferencing a NULL > > pointer at offset 0x10008 here? Wow, that's ... crazy. > > > > Not sure what to do now - wait for the bug to get resolved? Compile the > > s390-ccw bios with -Wno-stringop-overread ? Add "volatiles" here and there > > to hope that these silence the compiler warnings? ... I tend to wait for the > > bug ticket to see whether the GCC folks change the behavior of the compiler > > again, but I'm open for other suggestions. > > Assuming it is just this one place in the code ,then we should just > use "pragma" to temporarily disable/re-enable that single warning flag > either side of the problem. The gcc bug report suggests that use of 'volatile' also sidesteps the warning. Is that a sensible approach here ? thanks -- PMM
Re: [PATCH v4 03/28] cpu: Introduce cpu_virtio_is_big_endian()
Hi Michael, On 3/4/21 8:51 AM, Greg Kurz wrote: > On Wed, 3 Mar 2021 17:08:32 -0500 > "Michael S. Tsirkin" wrote: > >> On Wed, Mar 03, 2021 at 10:46:43PM +0100, Philippe Mathieu-Daudé wrote: >>> Introduce the cpu_virtio_is_big_endian() generic helper to avoid >>> calling CPUClass internal virtio_is_big_endian() one. >>> >>> Signed-off-by: Philippe Mathieu-Daudé >> >> Using virtio in the name here probably because virtio wants this? >> That doesn't sound like a good naming strategy, name should >> tell us what function does not how it's used. >> > > I tend to agree but there was a consensus to deliberately put > virtio in the name when this was first introduced, so that > nobody else ever try to use it, as recorded in the commit log. > > commit bf7663c4bd8f8f619d6dbb5780025d92ace250a8 > Author: Greg Kurz > Date: Tue Jun 24 19:33:21 2014 +0200 > > cpu: introduce CPUClass::virtio_is_big_endian() > > If we want to support targets that can change endianness (modern PPC and > ARM for the moment), we need to add a per-CPU class method to be called > from the virtio code. The virtio_ prefix in the name is a hint for people > to avoid misusage (aka. anywhere but from the virtio code). > > The default behaviour is to return the compile-time default target > endianness. > > Suggested-by: Peter Maydell > Signed-off-by: Greg Kurz > Reviewed-by: Michael S. Tsirkin > Signed-off-by: Michael S. Tsirkin > > Is there something new on this front ? I'm not convinced that anything > but legacy virtio en POWER (or any other target that can change endian > at runtime) needs this. The next step I see for this is_big_endian() > stuff is deprecation and removal. In the meantime, I think we should > keep the virtio wording to prevent additional users for this. On 3/3/21 11:15 PM, Michael S. Tsirkin wrote: > On a more concrete proposal, how about using this change > to rename the virtio_is_big_endian field to guest_is_big_endian(), > and put the wrapper somewhere in a virtio header instead? Due to Greg comment, I'll keep cpu_virtio_is_big_endian() in the v5 respin. This doesn't seem a real blocker for the rest of the changeset. We can settle the name and send a patch on top. Regards, Phil.
Re: [PATCH v4 00/28] cpu: Introduce SysemuCPUOps structure, remove watchpoints from usermode
On 3/4/21 2:52 AM, Richard Henderson wrote: > On 3/3/21 1:46 PM, Philippe Mathieu-Daudé wrote: >> Patches 1-6 are generic cleanups. >> Patches 7-15 move from CPUClass to SysemuCPUOps >> Patch 16 restricts SysemuCPUOps to sysemu >> Patches 17-26 remove watchpoint code from user emulation >> Patches 27-28 remove USER_ONLY #ifdef'ry from "cpu.h" > > Patches 1-18: > Reviewed-by: Richard Henderson > > While mst has asked for a name change vs patch 4, I think that if we do > that it should be separate, because it would involve a rename through > hw/ as well. > > The watchpoint patches that follow need some more careful thought. OK. I'll respin without the watchpoint part (first half). Thanks, Phil.
[Bug 1920752] Re: USB SoundCard Passthrough not working on arm64
I ran it as follows: qemu-system-aarch64 -M virt -m 2048 -smp 2 -cpu host,aarch64=off -enable-kvm -kernel vmlinuz-4.19.0-14-armmp-lpae -initrd initrd.img-4.19.0-14-armmp-lpae -append 'root=/dev/vda2' -device nec- usb-xhci -device usb-kbd -device usb-mouse -device usb- host,pcap=test.pcap,hostbus=1,hostport=2.1 -serial stdio -device virtio- gpu-pci,virgl=on,xres=1600,yres=900 -display sdl,gl=on -drive if=none,file=hda2.qcow2,format=qcow2,id=hd -device virtio-blk- device,drive=hd -netdev user,id=mynet -device virtio-net- device,netdev=mynet -bios edk2-arm-code.fd -no-reboot But the pcap file is empty: file test.pcap test.pcap: empty -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1920752 Title: USB SoundCard Passthrough not working on arm64 Status in QEMU: New Bug description: Hello, I am virtualizing a armhf guest on a aarch64 host and was to use my Sound Blaster USB Soundcard as passthrough. armhf Guest is: Debian Buster aarch64 host is a jetson nano. KVM is enabled. Latest qemu is built from sources. The command I use for running is as follows: ../qemu/build/qemu-system-aarch64 -M virt -m 2048 -smp 2 -cpu host,aarch64=off -enable-kvm \ -kernel vmlinuz-4.19.0-14-armmp-lpae -initrd initrd.img-4.19.0-14-armmp-lpae -append 'root=/dev/vda2' \ -device nec-usb-xhci -device usb-kbd -device usb-mouse -device usb-host,hostbus=1,hostport=2.3 -serial stdio \ -device virtio-gpu-pci,virgl=on,xres=1600,yres=900 -display sdl,gl=on \ -drive if=none,file=hda2.qcow2,format=qcow2,id=hd -device virtio-blk-device,drive=hd \ -netdev user,id=mynet -device virtio-net-device,netdev=mynet \ -bios edk2-arm-code.fd -no-reboot Where are my lsusb -t shows: rreddy78@jetson-nano:~/Downloads$ lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 5000M |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/5p, 480M |__ Port 2: Dev 6, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 1: Dev 7, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 1: Dev 7, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 3: Dev 8, If 3, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 3: Dev 8, If 1, Class=Audio, Driver=snd-usb-audio, 12M |__ Port 3: Dev 8, If 2, Class=Audio, Driver=snd-usb-audio, 12M |__ Port 3: Dev 8, If 0, Class=Audio, Driver=snd-usb-audio, 12M |__ Port 4: Dev 9, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M Within the VM I can see the usb as follows rreddy78@debian:~$ lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 480M Its looks like some passthrough as but it seems like only for _ Port 3: Dev 8, If 3, Class=Human Interface Device, Driver=usbhid, 12M I am not sure if passthrough even works because this post I saw https://community.arm.com/developer/ip-products/system/f/embedded- forum/48031/usb-pass-through-in-qemu-command-line-for-arm- machines/168764#168764 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1920752/+subscriptions
Re: [PATCH] Set the correct env->fpip for x86 float instructions [cleaned]
Ping for this patch. Patchew: https://patchew.org/QEMU/20210416153430.92187-1-ziqiaok...@gmail.com/ Ziqiao. On Fri, Apr 16, 2021 at 11:38 PM Ziqiao Kong wrote: > > Hello, everyone! > > Sorry that I forgot the Signed-off-by line and put the duplicate link just > now. Please ignore my previous emails. > > This patch follows > https://lists.gnu.org/archive/html/qemu-devel/2010-11/msg02497.html and > https://lists.nongnu.org/archive/html/qemu-devel/2021-04/msg00307.html > > Sorry again for any inconvenience. > > Signed-off-by: Ziqiao Kong > --- > target/i386/tcg/fpu_helper.c | 4 ++-- > target/i386/tcg/translate.c | 3 +++ > 2 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/target/i386/tcg/fpu_helper.c b/target/i386/tcg/fpu_helper.c > index 60ed93520a..e8cbde4e1a 100644 > --- a/target/i386/tcg/fpu_helper.c > +++ b/target/i386/tcg/fpu_helper.c > @@ -2395,7 +2395,7 @@ static void do_fstenv(CPUX86State *env, target_ulong > ptr, int data32, > cpu_stl_data_ra(env, ptr, env->fpuc, retaddr); > cpu_stl_data_ra(env, ptr + 4, fpus, retaddr); > cpu_stl_data_ra(env, ptr + 8, fptag, retaddr); > -cpu_stl_data_ra(env, ptr + 12, 0, retaddr); /* fpip */ > +cpu_stl_data_ra(env, ptr + 12, env->fpip, retaddr); /* fpip */ > cpu_stl_data_ra(env, ptr + 16, 0, retaddr); /* fpcs */ > cpu_stl_data_ra(env, ptr + 20, 0, retaddr); /* fpoo */ > cpu_stl_data_ra(env, ptr + 24, 0, retaddr); /* fpos */ > @@ -2404,7 +2404,7 @@ static void do_fstenv(CPUX86State *env, target_ulong > ptr, int data32, > cpu_stw_data_ra(env, ptr, env->fpuc, retaddr); > cpu_stw_data_ra(env, ptr + 2, fpus, retaddr); > cpu_stw_data_ra(env, ptr + 4, fptag, retaddr); > -cpu_stw_data_ra(env, ptr + 6, 0, retaddr); > +cpu_stw_data_ra(env, ptr + 6, env->fpip, retaddr); > cpu_stw_data_ra(env, ptr + 8, 0, retaddr); > cpu_stw_data_ra(env, ptr + 10, 0, retaddr); > cpu_stw_data_ra(env, ptr + 12, 0, retaddr); > diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c > index 880bc45561..cc4398f03b 100644 > --- a/target/i386/tcg/translate.c > +++ b/target/i386/tcg/translate.c > @@ -6337,7 +6337,10 @@ static target_ulong disas_insn(DisasContext *s, > CPUState *cpu) > goto unknown_op; > } > } > +tcg_gen_movi_tl(s->tmp0, pc_start - s->cs_base); > +tcg_gen_st_tl(s->tmp0, cpu_env, offsetof(CPUX86State, fpip)); > break; > + > // > /* string ops */ > > -- > 2.25.1 >
