[Qemu-devel] [PATCH v2 1/1] xlnx-zcu102: Specify the number of max CPUs
Specify the number of CPUs that can run on ZynqMP.
Signed-off-by: Alistair Francis
Reviewed-by: Philippe Mathieu-Daud
---
V2:
- Use macros
hw/arm/xlnx-zcu102.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/arm/xlnx-zcu102.c b/hw/arm/xlnx-zcu102.c
index 519a16ed98..e2d15a1c9d 100644
--- a/hw/arm/xlnx-zcu102.c
+++ b/hw/arm/xlnx-zcu102.c
@@ -240,6 +240,7 @@ static void xlnx_zcu102_machine_class_init(ObjectClass *oc,
void *data)
mc->block_default_type = IF_IDE;
mc->units_per_default_bus = 1;
mc->ignore_memory_transaction_failures = true;
+mc->max_cpus = XLNX_ZYNQMP_NUM_APU_CPUS + XLNX_ZYNQMP_NUM_RPU_CPUS;
}
static const TypeInfo xlnx_zcu102_machine_init_typeinfo = {
--
2.11.0
Re: [Qemu-devel] [PATCH] tcg: Avoid setting tcg_initialize if !CONFIG_TCG
On 28.10.2017 00:54, Paolo Bonzini wrote: > On 26/10/2017 21:03, Philippe Mathieu-Daudé wrote: >>> AFAIK the only target that is so far supposed to work with >>> --disable-tcg is i386. The configure script however lets you try to >>> build without TCG if the host has an alternative accelerator (e.g. KVM), >>> but that build is likely to fail. [ just confirmed this with aarch64 ] >> What about s390x? > > s390x and ppc64 supposedly support --disable-tcg? s390x supports --disable-tcg, but ppc64 does not support it yet. Thomas
Re: [Qemu-devel] iotest 194 fails on vhdx
On 28/10/2017 08:57, Alexey Kardashevskiy wrote: > On 27/10/17 18:12, Jeff Cody wrote: >> VHDX does not support migration (VMDK fails the same way). > > Probably a very ignorant question but how can an image format not support > migration at all? Is not it simple writing blocks, one-by-one? Thanks. VHDX does not implement bdrv_invalidate_cache. If you add that callback, it can support migration. Paolo
Re: [Qemu-devel] [PULL 0/3] xen-20171026-tag
On 26 October 2017 at 23:59, Stefano Stabellini wrote: > The following changes since commit 325a084c1ebccb265a3c8f1dd092ffbbfb448a00: > > Merge remote-tracking branch > 'remotes/stefanberger/tags/pull-tpm-2017-10-24-1' into staging (2017-10-26 > 09:20:11 +0100) > > are available in the git repository at: > > > git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20171026-tag > > for you to fetch changes up to 7cdcca725b6bfc96634c15e3f74ae4b148cf9c40: > > xen: Log errno rather than return value (2017-10-26 14:26:48 -0700) > > > Xen 2017/10/26 > > > Juergen Gross (2): > xen: add a global indicator for grant copy being available > xen: dont try setting max grants multiple times > > Ross Lagerwall (1): > xen: Log errno rather than return value Applied, thanks. -- PMM
[Qemu-devel] [Bug 1192499] Re: virsh migration copy-storage-all fails with "Unable to read from monitor: Connection reset by peer"
Launchpad has imported 15 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=979411. If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. On 2013-06-28T13:15:38+00:00 chandrashekar wrote: Created attachment 766573 Source-migrate-logs Description of problem: virsh migration copy-storage-all fails with "Unable to read from monitor: Connection reset by peer" and shut downs the guest on the source host. Kernel Version: 3.10.0-rc5+ Libvirt Version: 1.0.6 Qemu Version: 1.5.50 Steps to Reproduce: 1. Created the qemu-img create -f qcow2 vm.qcow2 11G on the destination host which is same as the source. 2. Started the guest on the source 3. Started the vncdisplay to monitor the guest 4. Initiated the migration "virsh migrate --live VM1 qemu+ssh://host-ip/system tcp://host-ip --verbose --copy-storage-all" 5. It started the copying the storage from souce to destination (conitinously monitored it was growing) 6. Guest on the destination was paused and was running on the source 7. At some point the VM on the source got shutdown and migration failed with "Unable to read from monitor: Connection reset by peer" Attached the libvirt debug logs. The debug logs shows : 2013-06-19 08:43:12.253+: 4026: debug : virEventPollInterruptLocked:716 : Interrupting 2013-06-19 08:43:12.253+: 4026: debug : virEventPollAddTimeout:248 : EVENT_POLL_ADD_TIMEOUT: timer=1 frequency=0 cb=0x7fe930baa960 opaque=(nil) ff=(nil) Note: The virsh live migration works fine with nfs storage from source to destination and vice versa. With libvirt 1.0.5 and qemu 1.5 also we were facing the same issue, but with that even "Live migration with nfs also was not working". Guest XML: VM1 47feb0e1-0c23-9be9-da12-2ead34864de2 4096000 2048000 1 hvm destroy restart restart /usr/local/bin/qemu-system-x86_64 Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1192499/comments/2 On 2013-06-28T13:27:20+00:00 Michal wrote: Can you provide the destination debug logs? Esp. content of /var/log/libvirt/qemu/VM1.log as there's supposed to be the reason why qemu died. Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1192499/comments/3 On 2013-06-28T13:59:18+00:00 chandrashekar wrote: Created attachment 766578 Source Logs Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1192499/comments/4 On 2013-06-28T13:59:51+00:00 chandrashekar wrote: Created attachment 766579 Destination Logs Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1192499/comments/5 On 2013-06-28T14:20:28+00:00 Michal wrote: >From the VM1_dest.log: ... Completed 97 % Completed 98 % Completed 99 % qemu: warning: error while loading state section id 1 load of migration failed So the qemu is unable to migrate itself. Therefore I think this is actually a qemu bug. On the other hand, I wonder why the guest on the source is shut down. There's no sign of that in the logs. Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1192499/comments/6 On 2013-07-01T10:02:08+00:00 chandrashekar wrote: When the migration fails the guest gets shutdown on the source. [root@9 images]# virsh list --all IdName State 5 VM1 running [root@9 images]# virsh migrate --live rhel64-64 qemu+ssh:/IP/system tcp://IP --verbose --copy-storage-all Migration: [ 93 %]error: Unable to read from monitor: Connection reset by peer At the destination: [root@9 images]# virsh list --all IdName State - VM1 shut off [root@destination]# virsh list --all IdName State 16VM1 paused [root@destination]# virsh list --all IdName State Reply at: https://bugs.launchpad.ne
[Qemu-devel] [Bug 1336123] Re: bad switch, segfault in hw/pci-host/bonito.c bonito_readl
I think this might have been fixed with this commit here: https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0ca4f94195cce77b624ed Or can you still reproduce it with the current version of QEMU? ** 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/1336123 Title: bad switch, segfault in hw/pci-host/bonito.c bonito_readl Status in QEMU: Incomplete Bug description: http://git.qemu.org/?p=qemu.git;a=blob;f=hw/pci- host/bonito.c;h=56292adb03cd1a9873c2c9e5a0b2978fd0572214;hb=master#l301 The switch statement is error-prone, since two branches return the same result. Segfault reproducing steps: 1. make a Linux kernel(for example 3.16.0-rc2) with fuloong2e_defconfig 2. use 'qemu-system-mips64el -machine fulong2e' to boot the vmlinux qemu versions tried: 2.0.0, 1.6.2 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1336123/+subscriptions
[Qemu-devel] [Bug 1358287] Re: -readconfig file doesn't interpret memory size correctly
Triaging 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/1358287 Title: -readconfig file doesn't interpret memory size correctly Status in QEMU: Incomplete Bug description: I'm running Qemu 2.1 and have issues with the config file format. Specifically Qemu wrote the following snippet with '-writeconfig': [memory] size = "1024" However, upon starting a VM with this setting it only receives 128MiB (the default size). I'm reverting back to using the command line option now - that works. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1358287/+subscriptions
[Qemu-devel] [Bug 1338957] Re: RFE: add an event to report block devices watermark
Upstream here: https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e2462113b2003085ad16f15e1 ** 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/1338957 Title: RFE: add an event to report block devices watermark Status in QEMU: Fix Released Bug description: Add an event to report if a block device usage exceeds a threshold. The threshold should be configurable with a monitor command. The event should report the affected block device. Additional useful information could be the offset of the highest sector , like in the query- blockstats output. Rationale for the RFE Managing applications, like oVirt (http://www.ovirt.org), make extensive use of thin-provisioned disk images. In order to let the guest run flawlessly and be not unnecessarily paused, oVirt sets a watermark and automatically resized the image once the watermark is reached or exceeded. In order to detect the mark crossing, the managing application has no choice than aggressively polling the QEMU monitor using the query-blockstats command. This lead to unnecessary system load, and is made even worse under scale: scenarios with hunderds of VM are becoming not unusual. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1338957/+subscriptions
[Qemu-devel] [Bug 1332297] Re: qemu-img: crash on check of an image with large value in the 'size' header field
QEMU nowadays seems to report "Check failed: Cannot allocate memory" ... so I assume that is OK and we can now close this bug? ** 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/1332297 Title: qemu-img: crash on check of an image with large value in the 'size' header field Status in QEMU: Incomplete Bug description: The qemu-img crashes on the next command: qemu-img check test_image 'test_image' can be found in the attachment. It's a fuzzed test image with the qcow2 image header only. Suppositional cause of the failure is the value of 'size' header field set to maximum uint_64 value. System information: qemu.git: 6baa963f4dcc2118 Host: Linux 3.14.7-200.fc20.x86_64 #1 SMP Wed Jun 11 22:38:05 UTC 2014 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1332297/+subscriptions
[Qemu-devel] [Bug 1338591] Re: Cursor jumps on shape change with vmware vga
Triaging 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/1338591 Title: Cursor jumps on shape change with vmware vga Status in QEMU: Incomplete Bug description: I launch QEMU with the following command line: qemu-system-i386 /home/ruslan/iso/Windoze/qemuxp.img -m 512 -display sdl -vga vmware -enable-kvm The guest OS is Windows XP. To reproduce the problem, do this: 0. Make sure guest is WinXP (don't know if it's really necessary), use vmware VGA 1. Set mouse cursor theme to default black&white theme, i.e. that without any translucency etc. 2. Open a text editor, e.g. built-in notepad 3. Move the cursor inside text entry widget 4. See the cursor jumping away. You basically can't enter the cursor there. This also reproduces with MS Word 2003 even with oxy-white cursor theme (i.e. that with translucency) — seems Word uses its plain black&transparent cursor for I-beam cursor. This doesn't happen with other VGAs, i.e. cirrus and std. I used qemu git master to test this. qemu-system-i386 --version reports version 2.0.90, git describe says v2.1.0-rc0-1-g9d9de25. This also happened in earlier QEMU versions, like 1.5.x and older. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1338591/+subscriptions
[Qemu-devel] [Bug 1307225] Re: Running a virtual machine on a Haswell system produces machine check events
Triaging 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/1307225
Title:
Running a virtual machine on a Haswell system produces machine check
events
Status in QEMU:
Incomplete
Bug description:
I'm running a virtual Windows SBS 2003 installation on a Xeon E3
Haswell system running Gentoo Linux. First, I used Qemu 1.5.3 (the
latest stable version on Gentoo). I got a lot of machine check events
("mce: [Hardware Error]: Machine check events logged") in dmesg that
always looked like (using mcelog):
Hardware event. This is not a software error.
MCE 0
CPU 3 BANK 0
TIME 1397455091 Mon Apr 14 07:58:11 2014
MCG status:
MCi status:
Corrected error
Error enabled
MCA: Internal parity error
STATUS 904f0005 MCGSTATUS 0
MCGCAP c09 APICID 6 SOCKETID 0
CPUID Vendor Intel Family 6 Model 60
I found this discussion on the vmware community:
https://communities.vmware.com/thread/452344
It seems that this is (at least partly) caused by the Qemu machine. I
switched to Qemu 1.7.0, the first version to use "pc-i440fx-1.7". With
this version, the errors almost disappeared, but from time to time, I
still get machine check events. Anyways, they so not seem to affect
neither the vm, nor the host.
The Haswell machine has been set up and running for several days
without a single error message. They only appear when the VM is
running. so I think this is actually some problem with the Haswell
architecture (and not a real hardware error).
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1307225/+subscriptions
[Qemu-devel] [Bug 1318091] Re: Perfctr MSRs not available to Guest OS on AMD Phenom II
Triaging 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/1318091 Title: Perfctr MSRs not available to Guest OS on AMD Phenom II Status in QEMU: Incomplete Bug description: The AMD Phenom(tm) II X4 965 Processor (family 16, model 4, stepping 3) has the 4 architecturally supported perf counters at MSRs. The selectors are c001000-c001003, and the counters are c001004-c001007. I've verified that the MSRs are there and working by manually setting the MSRs with msr-tools to count cycles. The processor does not support the extended perfctr or the perfctr_nb. These are in cpuid leaf 8000_0001. Qemu also sees that these cpuid flags are not set, when I try launching with -cpu host,perfctr_core,check. However, this flag is only for the extended perfctr MSRs, which also happen to map the original four counters at c0010200. When I run a Guest OS, that OS is unable to use the perf counter registers from c001000-7. rdmsr and wrmsr complete, but the results are always 0. By contrast, a wrmsr to one of the c0010200 registers causes a general protection fault (as it should, since those aren't supported). Kernel: 3.14.0-gentoo Qemu: 2.0.0 (gentoo) and also with 2.0.50 (commit 06b4f00d5) Qemu command: qemu-system-x86_64 -enable-kvm -cpu host -smp 8 -m 1024 -nographic -monitor /dev/pts/4 mnt/hdd.img cat /proc/cpuinfo: processor : 3 vendor_id : AuthenticAMD cpu family: 16 model : 4 model name: AMD Phenom(tm) II X4 965 Processor stepping : 3 cpu MHz : 800.000 cache size: 512 KB physical id : 0 siblings : 4 core id : 3 cpu cores : 4 apicid: 3 initial apicid: 3 fpu : yes fpu_exception : yes cpuid level : 5 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 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate npt lbrv svm_lock nrip_save bogomips : 6803.79 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1318091/+subscriptions
[Qemu-devel] [Bug 1314857] Re: seg fault in ivshmem when using ioeventfd=on
Fix had been included here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e9d21c436f716603b3
** 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/1314857
Title:
seg fault in ivshmem when using ioeventfd=on
Status in QEMU:
Fix Released
Status in qemu-kvm package in Ubuntu:
Confirmed
Bug description:
When launching qemu with the ivshmem device and the nahanni guest
server there is segmentation fault in the setup_ioeventfds function of
ivshmem.c. If the ioeventfd=on flag is set the pci_ivshmem_init will
call setup_ioeventfds at line 668. This function relies on the 'peers'
member of the server info which is not allocated until line 669.
To reproduce you will need the nahanni guest server code. The driver
code is not needed. You will also need a qcow2 or other bootable image
to use for launching qemu. The error occurs before the actual image
launch.
Start the nahanni ivshmem server with a small global memory space ( although
the bug is not allocation specific )
ivshmem -m 1 -n 2 -p /tmp/ivshmem_socket
Next launch qemu with initialization for the ivshmem device.
qemu-system-x86_64 -hda test_iso.qcow2 -localtime -boot c -chardev
socket,path="/tmp/ivshmem_socket",id=ivshmem_socket -device
ivshmem,chardev=ivshmem_socket,size=1,ioeventfd=on
If gdb is used the following error is recorded:
Program received signal SIGSEGV, Segmentation fault.
0x5579dd52 in setup_ioeventfds (s=0x56619580)
at /home/genes/work/ubuntu/qemu-kvm-1.0+noroms/hw/ivshmem.c:367
367 for (j = 0; j < s->peers[i].nb_eventfds; j++) {
(gdb) print s->peers
$2 = (Peer *) 0x0
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1314857/+subscriptions
[Qemu-devel] [Bug 1297781] Re: Network device cannot communicate with host machine
Triaging old bug tickets ... How did you start QEMU here? Can you still reproduce this issue with the latest version of QEMU? ** 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/1297781 Title: Network device cannot communicate with host machine Status in QEMU: Incomplete Bug description: I know this used to work but it doesnt work any more using qemu 1.4.2 on fedora 19 everything works fine except when i add a NIC sharing the main interface from the host (not the virtual network) the hosts ip is 10.0.0.4, the router is 10.0.0.1 so when i boot my virtual machine it gets an ip from the router no problem i get on the internet fine, and i can connect (ping,ftp, samba whatever) to all the computers on the network except the host 10.0.0.4 i can't ping it, i cant do anything to it, but i can connect to all the other computers on the network and i know i used to be able to do this because thats how i shared files between the host and windows guest, with samba... but now i can't browse the host computer because it can't communicate... please help. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1297781/+subscriptions
[Qemu-devel] [Bug 1296882] Re: add next free device option to qemu-img
** 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/1296882 Title: add next free device option to qemu-img Status in QEMU: New Bug description: I'd like to propose an option to be added to qemu-img which returns the next free NBD (the device file) very similar to losetup -f. It would make life a lot easier. Followers of this enhancement request might be interested in the following workaround: http://stackoverflow.com/questions/22535222 /next-free-device-option-for-qemu-nbd/ To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1296882/+subscriptions
[Qemu-devel] [Bug 1310714] Re: User mode networking SLIRP rapid memory leak
Triaging 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/1310714 Title: User mode networking SLIRP rapid memory leak Status in QEMU: Incomplete Bug description: QEMU compiled from git HEAD at 2d03b49c3f225994c4b0b46146437d8c887d6774 and reproducible at tag v2.0.0. I first noticed this bug using Ubuntu Trusty's QEMU 2.0.0~rc1. I used to run QEMU 1.7 without this problem. This is the command I ran: qemu-system-x86_64 -enable-kvm -smp 2 -m 1G -usbdevice tablet -net nic,model=e1000 -net user -vnc localhost:99 -drive if=ide,file=test.img,cache=none -net nic -net user,tftp=/tmp/tftpdata -no-reboot The guest is Windows 7 64-bit. The VM starts off normally, but after a couple of minutes, the memory usage starts to swell. If let running, it eventually consumes all host memory and grinds the host to a halt due to heavy swapping. When running under gdb, I set a breakpoint on mmap, and this is the stack trace I obtained. Breakpoint 1, mmap64 () at ../sysdeps/unix/syscall-template.S:81 81in ../sysdeps/unix/syscall-template.S (gdb) where #0 mmap64 () at ../sysdeps/unix/syscall-template.S:81 #1 0x70e65091 in new_heap (size=135168, size@entry=1728, top_pad=) at arena.c:554 #2 0x70e687b2 in sysmalloc (av=0x7fffd020, nb=1664) at malloc.c:2386 #3 _int_malloc (av=0x7fffd020, bytes=1650) at malloc.c:3740 #4 0x70e69f50 in __GI___libc_malloc (bytes=1650) at malloc.c:2855 #5 0x557a091a in m_get (slirp=0x561fe960) at /src/qemu/slirp/mbuf.c:73 #6 0x557a3151 in slirp_input (slirp=0x561fe960, pkt=0x77e94b20 "RU\n", pkt_len=) at /src/qemu/slirp/slirp.c:747 #7 0x55758b24 in net_slirp_receive (nc=, buf=, size=54) at /src/qemu/net/slirp.c:113 #8 0x557567d1 in qemu_deliver_packet (sender=, flags=, data=, size=, opaque=) at /src/qemu/net/net.c:471 #9 0x557588d3 in qemu_net_queue_deliver (size=54, data=0x77e94b20 "RU\n", flags=0, sender=0x561fe5e0, queue=0x561fe1d0) at /src/qemu/net/queue.c:157 #10 qemu_net_queue_send (queue=0x561fe1d0, sender=0x561fe5e0, flags=0, data=0x77e94b20 "RU\n", size=54, sent_cb=) at /src/qemu/net/queue.c:192 ---Type to continue, or q to quit--- #11 0x5575536b in net_hub_receive (len=54, buf=0x77e94b20 "RU\n", source_port=0x561fe310, hub=) at /src/qemu/net/hub.c:55 #12 net_hub_port_receive (nc=0x561fe310, buf=0x77e94b20 "RU\n", len=54) at /src/qemu/net/hub.c:114 #13 0x557567d1 in qemu_deliver_packet (sender=, flags=, data=, size=, opaque=) at /src/qemu/net/net.c:471 #14 0x557588d3 in qemu_net_queue_deliver (size=54, data=0x77e94b20 "RU\n", flags=0, sender=0x56531920, queue=0x561fe090) at /src/qemu/net/queue.c:157 #15 qemu_net_queue_send (queue=0x561fe090, sender=0x56531920, flags=0, data=0x77e94b20 "RU\n", size=54, sent_cb=) at /src/qemu/net/queue.c:192 #16 0x556db95d in xmit_seg (s=0x77e72010) at /src/qemu/hw/net/e1000.c:628 #17 0x556dbd38 in process_tx_desc (dp=0x7fffdf7fda30, s=0x77e72010) at /src/qemu/hw/net/e1000.c:723 #18 start_xmit (s=0x77e72010) at /src/qemu/hw/net/e1000.c:778 #19 set_tctl (s=0x77e72010, index=, val=) at /src/qemu/hw/net/e1000.c:1142 #20 0x55840fb0 in access_with_adjusted_size (addr=14360, value=0x7fffdf7fdb10, size=4, access_size_min=, access_size_max=, ---Type to continue, or q to quit--- access=0x55841160 , mr=0x77e747c0) at /src/qemu/memory.c:478 #21 0x558462fe in memory_region_dispatch_write (size=4, data=454, addr=14360, mr=0x77e747c0) at /src/qemu/memory.c:990 #22 io_mem_write (mr=0x77e747c0, addr=14360, val=, size=4) at /src/qemu/memory.c:1744 #23 0x557e8717 in address_space_rw ( as=0x56159c80 , addr=4273485848, buf=0x77fed028 "\306\001", len=4, is_write=true) at /src/qemu/exec.c:2034 #24 0x5583ff65 in kvm_cpu_exec (cpu=) at /src/qemu/kvm-all.c:1704 #25 0x557ddb6c in qemu_kvm_cpu_thread_fn (arg=0x5651b730) at /src/qemu/cpus.c:873 #26 0x711b6182 in start_thread (arg=0x7fffdf7fe700) at pthread_create.c:312 #27 0x70ee1b2d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Let me know if you have any questions. Thanks. liulk To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1310714/+subscriptions
[Qemu-devel] [Bug 1288259] Re: KVM vms are paused and cannot be deleted due to hardware error 0x0
** Project changed: qemu => qemu (Ubuntu) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1288259 Title: KVM vms are paused and cannot be deleted due to hardware error 0x0 Status in qemu package in Ubuntu: New Bug description: Upon creation of instances via OpenStack nova api instances got stuck in spawning state. Then, after trying to delete instances they got stuck in deleting state. After investigation the following error was found: KVM: entry failed, hardware error 0x0 EAX= EBX= ECX= EDX=0623 ESI= EDI= EBP= ESP= EIP=fff0 EFL=0002 [---] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES = 9300 CS =f000 000f f300 SS = f300 DS = 9300 FS = 9300 GS = 9300 LDT= 8200 TR = 8b00 GDT= IDT= CR0=6010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=28 95 66 ba 01 4a 03 00 66 89 d8 66 5b 66 5e e9 15 79 66 c3 5b e0 00 f0 30 36 2f 32 33 2f 39 39 00 fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 All instances were in paused state: root@node-7:~# virsh list setlocale: No such file or directory IdName State 4 instance-0004 paused 5 instance-0005 paused 6 instance-0006 paused 7 instance-0007 paused 8 instance-0008 paused 9 instance-0009 paused The only way to delete VM is to reset it and then resume it. After this, VM is deleted properly. OpenStack version: Havana on Ubuntu 12.04 KVM version: QEMU emulator version 1.2.0 (qemu-kvm-1.2.0+noroms-0ubuntu7.12.10, Debian), Copyright (c) 2003-2008 Fabrice Bellard To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1288259/+subscriptions
[Qemu-devel] [Bug 1292037] Re: Solaris 10 x86 guest crashes qemu with -icount 1 option
Triaging 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/1292037 Title: Solaris 10 x86 guest crashes qemu with -icount 1 option Status in QEMU: Incomplete Bug description: Solaris image: Solaris 10 x86 (32 bit) command: ./i386-softmmu/qemu-system-i386 -hda -m 2G -icount 1 -monitor stdio Crashes saying: qemu: Fatal: Raised interrupt while not in I/O function Host: ubuntu x86_64 3.2.0-56 generic intel xeon E5649 @ 2.53GHz UPDATE: Tested on QEMU v2.0.50 Also affects OpenIndiana (151a8 - Server Build 32bit) http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg06365.html Workaround: Rename the kvmvapic.bin file under the pc-bios directory to something different. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1292037/+subscriptions
[Qemu-devel] [Bug 1279500] Re: system_powerdown causes SMP OpenBSD guest to freeze
Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU and OpenBSD? 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/1279500 Title: system_powerdown causes SMP OpenBSD guest to freeze Status in QEMU: Incomplete Bug description: system_powerdown causes an SMP OpenBSD guest to freeze. I can reproduce it with the following systems/versions: - Debian 6: QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5) - Fedora 20: qemu-system-x86-1.6.1 (from Fedora repository) qemu-1.7.0 (latest release version) qemu-1.7.50 (latest development snapshot, "git cloned" today, 20140212) all of the above hosts are running x86_64 linux. The first OpenBSD version that I ran as a VM, v5.1, experienced the problem. All subsequent versions experience the problem. The above tests were performed using OpenBSD v5.4 (amd64). I will open an OpenBSD bug report for this problem as well, and update this report with the OpenBSD bug ID. There's an interesting RedHat bug report concerning this problem: URL: https://bugzilla.redhat.com/show_bug.cgi?id=508801#c34 Here an excerpt: -snip- Gleb Natapov 2009-12-23 10:37:44 EST I posted patch to provide correct PCI irq routing info in mptable to kvm mailing list. It works for all devices except for SCI interrupt. BIOS programs SCI interrupt to be 9 as spec requires, but OpenBSD thinks that it is smarter and moves it to interrupts 10. Qemu will still send it on vector 9 and OpenBSD will enter the same infinity recursion. This can be triggered by issuing system_powerdown on qemu monitor. -snip- Michael Tokarev reported this problem on the kvm mailing list in 2011: URL: http://www.spinics.net/lists/kvm/msg51311.html I compiled qemu as follows: -snip- cd qemu-src-dir mkdir -p bin/native cd bin/native ../../configure \ --prefix=/usr/local/qemu-dev-snapshot-20140212 \ --target-list=x86_64-softmmu \ --enable-kvm \ --enable-spice \ --with-gtkabi="3.0" \ --audio-drv-list=pa,sdl,alsa,oss \ --extra-cflags='-I/usr/include/SDL' -snip- I'm running OpenBSD with the following command: -snip- #!/bin/bash DEF=/usr/bin/qemu-system-x86_64 QEMU_LATEST=/usr/local/qemu-1.7.0/bin/qemu-system-x86_64 QEMU_DEV=/usr/local/qemu-dev-snapshot-20140212/bin/qemu-system-x86_64 $QEMU_DEV \ -machine accel=kvm \ -name obsdtest-v54 \ -S \ -machine pc-i440fx-1.6,accel=kvm,usb=off \ -boot c \ -m 2048 \ -realtime mlock=off \ -smp 2,sockets=2,cores=1,threads=1 \ -uuid 8b685793-2510-473e-b97e-822a4cf2fbca \ -no-user-config \ -monitor stdio \ -rtc base=utc,driftfix=slew \ -global kvm-pit.lost_tick_policy=discard \ -no-hpet \ -drive file=/guest_images/obsdtest_v54.raw,if=none,id=drive-virtio-disk0,format=raw,cache=none \ -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \ -drive if=none,id=drive-ide0-0-0,readonly=on,format=raw \ -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \ -chardev pty,id=charserial0 \ -device isa-serial,chardev=charserial0,id=serial0 \ -k en-us \ -device cirrus-vga,id=video0,bus=pci.0,addr=0x3 \ -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \ -net nic \ -net user -snip- The OpenBSD disk image I used for testing is 143MB compressed, 10G uncompressed. It can be found here: http://www.spielwiese.de/OpenBSD/obsd54.raw.7z The root password is "x". Rob Urban To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1279500/+subscriptions
[Qemu-devel] [Bug 1284874] Re: Guest hangs during option rom loading with certain cards
Patch seems to have been included here: https://git.qemu.org/?p=qemu.git;a=commitdiff;h=4b9430294ed406a00f045d ** 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/1284874 Title: Guest hangs during option rom loading with certain cards Status in QEMU: Fix Released Bug description: With a Broadcom Corporation NetXtreme II BCM57810 10 Gigabit Ethernet card, device assignment does not work. The guest hangs during option rom execution. Moreover, if an attempt is made to quit qemu when the guest is in the hung state, the card gets into an inoperable state. Only a powercycle then, restores the card back into working order, just unloading/loading the driver does not help. Qemu version - 1.6.2 or current master Distribution - FC19 Kernel Version - 3.12.9-201.fc19.x86_64 Details of the card - # ethtool -i p2p2 driver: bnx2x version: 1.78.17-0 firmware-version: bc 7.8.22 bus-info: :08:00.1 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes The output of lspci when the card is broken - 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM57810 10 Gigabit Ethernet (rev ff) (prog-if ff) !!! Unknown header type 7f Kernel driver in use: bnx2x 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff I will post if I get a chance to try out a newer than 7.8.22 for the option rom and see if this issue is fixed. However it appears we need to have a unified approach to automatically avoid loading the rom based on certain criteria. Manually, looking out for fixes to firmware and hard coding decisions based on those is neither desirable nor easy to maintain. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1284874/+subscriptions
[Qemu-devel] [Bug 1307225] Re: Running a virtual machine on a Haswell system produces machine check events
I'm not sure if this can still be reproduces but I've found a workaround
quite a while ago. The problem disappeared once I migrated the virtual
machines using 32 bit OS images to 64 bit. The mix of 32 and 64 bit VMs
was the causing these problems at least on my server.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1307225
Title:
Running a virtual machine on a Haswell system produces machine check
events
Status in QEMU:
Incomplete
Bug description:
I'm running a virtual Windows SBS 2003 installation on a Xeon E3
Haswell system running Gentoo Linux. First, I used Qemu 1.5.3 (the
latest stable version on Gentoo). I got a lot of machine check events
("mce: [Hardware Error]: Machine check events logged") in dmesg that
always looked like (using mcelog):
Hardware event. This is not a software error.
MCE 0
CPU 3 BANK 0
TIME 1397455091 Mon Apr 14 07:58:11 2014
MCG status:
MCi status:
Corrected error
Error enabled
MCA: Internal parity error
STATUS 904f0005 MCGSTATUS 0
MCGCAP c09 APICID 6 SOCKETID 0
CPUID Vendor Intel Family 6 Model 60
I found this discussion on the vmware community:
https://communities.vmware.com/thread/452344
It seems that this is (at least partly) caused by the Qemu machine. I
switched to Qemu 1.7.0, the first version to use "pc-i440fx-1.7". With
this version, the errors almost disappeared, but from time to time, I
still get machine check events. Anyways, they so not seem to affect
neither the vm, nor the host.
The Haswell machine has been set up and running for several days
without a single error message. They only appear when the VM is
running. so I think this is actually some problem with the Haswell
architecture (and not a real hardware error).
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1307225/+subscriptions
[Qemu-devel] [Bug 1276879] Re: lots of dma command 10, 14 not supported
Triaging 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/1276879 Title: lots of dma command 10, 14 not supported Status in QEMU: Incomplete Bug description: Trying to install NeXTSTEP 3.3 onto a 2GB file with QEMU 1.7.0. In the terminal that started QEMU, there are a lot of dma: command 10 not supported and dma: command 14 not supported messages. When the installation of NeXTSTEP gets to 'preparing disk for nextstep installation', there are a lot of messages that ATA command c5 failed and other info. The result is a failed installation. Is this a bug in QEMU? Is there a workaround, e.g. by disabling DMA altogether? thank you To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1276879/+subscriptions
[Qemu-devel] [Bug 921208] Re: win7/x64 installer hangs on startup with 0x0000005d.
Since there hasn't been a reply within the last 5 months, I assume this has been fixed and thus close now this ticket accordingly. ** 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/921208 Title: win7/x64 installer hangs on startup with 0x005d. Status in QEMU: Fix Released Status in qemu package in Ubuntu: Triaged Bug description: hi, during booting win7/x64 installer i'm observing a bsod with 0x005d ( msdn: unsupported_processor ). used command line: qemu-system-x86_64 -m 2048 -hda w7-system.img -cdrom win7_x64.iso -boot d adding '-machine accel=kvm' instead of default tcg accel helps to boot. installed software: qemu-1.0 linux-3.2.1 glibc-2.14.1 gcc-4.6.2 hw cpu: processor : 0..7 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz stepping: 7 microcode : 0x14 cpu MHz : 1995.739 cache size : 6144 KB physical id : 0 siblings: 8 core id : 3 cpu cores : 4 apicid : 7 initial apicid : 7 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 dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid bogomips: 3992.23 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/921208/+subscriptions
[Qemu-devel] [Bug 1272796] Re: Windows 98 First Edition emulation problems
Triaging 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/1272796 Title: Windows 98 First Edition emulation problems Status in QEMU: Incomplete Bug description: System: Debian SID x86 with latest updates 1) QEMU compiled from latest main GIT branch(at the time of writing, 1.7.50) (and 1.7 stable version) ./configure options: ./configure --enable-sdl --target-list=i386-softmmu --cpu=i686 --audio-drv-list=alsa When you try to boot Windows 98 First Edition (Italian), it does not simply boot. It stays on booting screen. If you try to install, the installation goes flawless, but when it boots it freeze. I am launching VM with this: qemu-system-i386 -hda main.img -cpu pentium -m 256 -fda floppy1.img -boot c -soundhw gus -vga cirrus I have tried with -M option "pc-i440fx-1.6" since 1.6 have no problems with the booting of Win98, but nothing. No fix found. 2) QEMU 1.6.2 (same compile and launching options) gus soundboard seems not recognized even with real dos drivers (tried to install theme into real dos mode). with SoundBlaster 16 i have following error: WARNING: I/O thread spun for 1000 iterations, making the emulation impossible (too slow, and sound is stuttering) . Tried to compile with oss and sdl option on audio-drv-list but no fix found. Any ideas? thank you To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1272796/+subscriptions
[Qemu-devel] [Bug 1268279] Re: Windows 7 x86 does not start on 1.7.50 from git
Triaging 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/1268279 Title: Windows 7 x86 does not start on 1.7.50 from git Status in QEMU: Incomplete Bug description: I have "Debian 7.2 x64". Install last QEMU from git: aptitude install git gcc make autoconf libglib2.0-dev libcurl4-gnutls- dev libpixman-1-dev libcap-dev libaio-dev libcap-ng-dev libjpeg8-dev libpng12-dev libssh2-1-dev uuid-dev #cd /usr/src #git clone git://git.qemu.org/qemu.git #cd qemu # ./configure --prefix=/usr --sysconfdir=/etc --target-list=x86_64-softmmu --enable-kvm Install prefix/usr BIOS directory/usr/share/qemu binary directory /usr/bin library directory /usr/lib libexec directory /usr/libexec include directory /usr/include config directory /etc local state directory /usr/var Manual directory /usr/share/man ELF interp prefix /usr/gnemul/qemu-%M Source path /usr/src/qemu C compilercc Host C compiler cc C++ compiler c++ Objective-C compiler cc ARFLAGS rv CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g QEMU_CFLAGS -Werror -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1 -I/usr/include/libpng12 -I/usr/include/pixman-1 LDFLAGS -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g make make install install pythonpython -B smbd /usr/sbin/smbd host CPU x86_64 host big endian no target list x86_64-softmmu tcg debug enabled no gprof enabled no sparse enabledno strip binariesyes profiler no static build no -Werror enabled yes pixmansystem SDL support yes GTK support no curses supportno curl support yes mingw32 support no Audio drivers oss Block whitelist (rw) Block whitelist (ro) VirtFS supportyes VNC support yes VNC TLS support yes VNC SASL support no VNC JPEG support yes VNC PNG support yes VNC WS supportyes xen support no brlapi supportno bluez supportno Documentation yes GUEST_BASEyes PIE yes vde support no netmap supportno Linux AIO support yes ATTR/XATTR support yes Install blobs yes KVM support yes RDMA support no TCG interpreter no fdt support no preadv supportyes fdatasync yes madvise yes posix_madvise yes sigev_thread_id yes uuid support yes libcap-ng support yes vhost-net support yes vhost-scsi support yes Trace backend nop Trace output file trace- spice support no (/) rbd support no xfsctl supportno nss used no libusbno usb net redir no GLX support yes libiscsi support no build guest agent yes QGA VSS support no seccomp support no coroutine backend ucontext coroutine poolyes GlusterFS support no virtio-blk-data-plane yes gcov gcov gcov enabled no TPM support no libssh2 support yes TPM passthrough no QOM debugging yes vhdx yes #make && make install QEMU is successfully builded and installed: # /usr/bin/qemu-system-x86_64 --version QEMU emulator version 1.7.50, Copyright (c) 2003-2008 Fabrice Bellard Create virtual HDD: # qemu-img create -f qcow2 /kvm/vm/test.img 50G Formatting '/kvm/vm/test.img', fmt=qcow2 size=53687091200 encryption=off cluster_size=65536 lazy_refcounts=off Start virtual machine: # /usr/bin/qemu-system-x86_64 -cpu qemu64 -M pc -smp 1 -m 1024 -monitor tcp:127.0.0.1:,server,nowait -drive file=/kvm/vm/test.img,cache=writeback,aio=native -boot order=dc,menu=on -enable-kvm -vnc 127.0.0.1:14 -localtime -no-hpet -rtc-td-hack -global kvm-pit.lost_tick_policy=discard -daemonize -usb -device usb-tablet,id=input0 -runas kvm Connect ISO image: # nc 127.0.0.1 QEMU 1.7.50 monitor - type 'help' for more information (qemu) change ide1-cd0 http://someiso.host.com/ru_windows_7_professional_with_sp1_x86_dvd.iso change ide1-cd0 http://someiso.host.com/ru_windows_7_professional_with_sp1_x86_dvd.iso (qemu) Open NVC console to VM, reboot and boot (F12) from connected IS
[Qemu-devel] [Bug 1261743] Re: trace-backend "simple" doesn't support "disable" property of event
I assume Stefan's fix had been included (likely https://git.qemu.org/?p=qemu.git;a=commitdiff;h=736ec1677f1ae7e64f2f ?), so I'm closing this ticket now. But if you still can reproduce this issue, please let us know. ** 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/1261743 Title: trace-backend "simple" doesn't support "disable" property of event Status in QEMU: Fix Released Bug description: trace-backend "simple" generates wrong eventid in trace/generated- tracers.c after "disable" property occured in trace-events record. Result: missing or mixing logs in trace file. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1261743/+subscriptions
[Qemu-devel] [Bug 1358287] Re: -readconfig file doesn't interpret memory size correctly
Good question. Over time I've got some feedback that the whole config file mechanism is really just a second class citizen anyway. I'm happy for now (running 2.7) and don't really care too much. Nevertheless: I'd be absolutely excited if I could reliably configure (and have nice documentation that I'd even be willing to help create) Qemu instances just with a config file ... Feel free to close this issue to get rid of old cruft ... :) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1358287 Title: -readconfig file doesn't interpret memory size correctly Status in QEMU: Incomplete Bug description: I'm running Qemu 2.1 and have issues with the config file format. Specifically Qemu wrote the following snippet with '-writeconfig': [memory] size = "1024" However, upon starting a VM with this setting it only receives 128MiB (the default size). I'm reverting back to using the command line option now - that works. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1358287/+subscriptions
[Qemu-devel] [Bug 1247478] Re: usb passthrough mass storage write data corruption
Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? Did you report it to the libusb folks? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1247478 Title: usb passthrough mass storage write data corruption Status in QEMU: New Bug description: the windows 7 professional guest writes to usb high speed mass storage devices connected via host-libusb in bulk packages of either size 20480 or 4096 (as far as the actual file data is concerned and except for the last packet for odd-sized files). The pattern is: 3 times bulk out 20480 1 time bulk out 4096 and that repeats for files longer than 65536 bytes. the file on the usb disk is corrupted and it is always corrupt in the last 4096 bytes of each 20480 byte sized transfer. that means a file is corrupt at 16384-20480 and 36864-40960 and 57344-61440. and so on. and because the 4096 sized bulk out is always error free, the next corrupt span is from 81920-86016. the last 4096 bytes of the 20480 sized transfer is always identical to the first 4096 bytes of the same transfer. to reproduce: run windows7 guest on and pass through usb2.0 disk with host-libusb. write a large file. (possibly check the bulk transfer sizes with usbmon). note that attaching usb disks with hw/usb/dev-storage does work just fine. cannot reproduce with linux as it always writes just 4096 bytes and writes with a linux guest are always ok even with usb passthrough. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1247478/+subscriptions
[Qemu-devel] [Bug 1247478] Re: usb passthrough mass storage write data corruption
** 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/1247478 Title: usb passthrough mass storage write data corruption Status in QEMU: Incomplete Bug description: the windows 7 professional guest writes to usb high speed mass storage devices connected via host-libusb in bulk packages of either size 20480 or 4096 (as far as the actual file data is concerned and except for the last packet for odd-sized files). The pattern is: 3 times bulk out 20480 1 time bulk out 4096 and that repeats for files longer than 65536 bytes. the file on the usb disk is corrupted and it is always corrupt in the last 4096 bytes of each 20480 byte sized transfer. that means a file is corrupt at 16384-20480 and 36864-40960 and 57344-61440. and so on. and because the 4096 sized bulk out is always error free, the next corrupt span is from 81920-86016. the last 4096 bytes of the 20480 sized transfer is always identical to the first 4096 bytes of the same transfer. to reproduce: run windows7 guest on and pass through usb2.0 disk with host-libusb. write a large file. (possibly check the bulk transfer sizes with usbmon). note that attaching usb disks with hw/usb/dev-storage does work just fine. cannot reproduce with linux as it always writes just 4096 bytes and writes with a linux guest are always ok even with usb passthrough. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1247478/+subscriptions
[Qemu-devel] [Bug 1246990] Re: [qemu-x86-64-linux-user 1.6.1] qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Triaging 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/1246990 Title: [qemu-x86-64-linux-user 1.6.1] qemu: uncaught target signal 11 (Segmentation fault) - core dumped Status in QEMU: Incomplete Status in qemu package in Ubuntu: Confirmed Bug description: Rjsupplicant is an authentication client of Campus Network in most universities in China. Its Linux version has only x86 and amd64 version. On linux: ./qemu-x86_64 is compiled from latest qemu 1.6.1, with ./configure options: --enable-debug --target-list=x86_64-linux-user . Compiler is gcc version 4.7.3 (Debian 4.7.3-4) $ sudo ./qemu-x86_64 ./rjsupplicant -n eth0 -u USER -p PASS -d 1 -s internet qemu: uncaught target signal 11 (Segmentation fault) - core dumped $ sudo gdb ./qemu-x86_64 (gdb) r ./rjsupplicant -n eth0 -u USER -p PASS -d 1 -s internet (gdb) where #0 0x559c21bd in static_code_gen_buffer () #1 0x555b74d5 in cpu_tb_exec (cpu=0x57972580, tb_ptr=0x559c2190 "A\213n\250\205\355\017\205\257") at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/cpu-exec.c:56 #2 0x555b817d in cpu_x86_exec (env=0x579726b0) at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/cpu-exec.c:631 #3 0x555d997a in cpu_loop (env=0x579726b0) at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/linux-user/main.c:283 #4 0x555eca6b in clone_func (arg=0x7fffc1d0) at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/linux-user/syscall.c:4266 #5 0x771bfe0e in start_thread (arg=0x77f04700) at pthread_create.c:311 #6 0x76ef493d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 $ file rjsupplicant rjsupplicant: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped $ uname -r 3.10-2-amd64 And it can be run on Linux amd64 successfully. Though I don't have the source code of rjsupplicant, so I don't have further information. `qemu-x86_64 -strace ./rjsupplicant -n eth0 -u USER -p PASS -d 1 -s internet` is attached as strace_qemu.log The binary is available to download at http://ge.tt/6pgG1tw/v/0 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1246990/+subscriptions
[Qemu-devel] [Bug 1239008] Re: qemu fails to scroll screen on ^Vidmem output
Triaging 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/1239008 Title: qemu fails to scroll screen on ^Vidmem output Status in QEMU: Incomplete Status in qemu package in Ubuntu: Incomplete Bug description: Pascal uses ^Vidmem for B800 console output. The terminal does not oblige the Pascal OS code to scroll the output. Virtualbox emulation works, so this must be a qemu bug. Using QEMU in KVM mode as Ubuntu LTS. Source line to trip bug(in theory pushes VideoMem up one line): procedure Scroll; //this is whats causing crashes. FIXME:Virtualbox not affected.QEMU BUG? begin if scrolldisabled then exit; if (CursorPosY >= 24) then begin //in case called before end of screen blank:= $20 or (TextAttr shl 8); Move((VidMem+(2*80))^,VidMem^,24*(2*80)); // Empty last line FillWord((VidMem+(24*2*80))^,80,Blank); CursorPosX:=1; CursorPosY:=23; update_cursor; end; end; To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1239008/+subscriptions
[Qemu-devel] [Bug 1007490] Re: Missing binfmt string for init script.
Triaging 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/1007490 Title: Missing binfmt string for init script. Status in QEMU: Incomplete Bug description: ./scripts/qemu-binfmt-conf.sh needs echo ':armCompiler:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x08\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin /qemu-static-arm-binfmt:P' > /proc/sys/fs/binfmt_misc/register Some executables (specifically compilers like /usr/libexec/gcc/armv7a- unknown-linux-gnueabi/4.5.3/cc1 on gentoo) have unusual headers, and don't get recognized as arm binaries. Bug also mentioned on my blog: http://mirage335.dyndns.org/forums/viewtopic.php?f=4&t=11&sid=01f0ca9cc76c78b6f600fa25cc99d62b To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1007490/+subscriptions
[Qemu-devel] [Bug 902720] Re: TIME_MAX not set correctly for OpenBSD in qemu-common.h
Triaging 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/902720 Title: TIME_MAX not set correctly for OpenBSD in qemu-common.h Status in QEMU: Incomplete Bug description: Looking at the OpenBSD buildbot logs I noticed a warning that appears to be a bug in the code. OpenBSD has a 32-bit time_t on all archs at the moment (32-bit and 64-bit). CCi386-softmmu/monitor.o /buildbot-qemu/default_openbsd_current/build/monitor.c: In function 'expire_password': /buildbot-qemu/default_openbsd_current/build/monitor.c:944: warning: overflow in implicit constant conversion qemu-common.h has... #ifndef TIME_MAX #define TIME_MAX LONG_MAX #endif for OpenBSD this should be INT_MAX. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/902720/+subscriptions
[Qemu-devel] [Bug 1307225] Re: Running a virtual machine on a Haswell system produces machine check events
Last time I saw this error in my mcelog was in August. Probably, some
update fixed it. I'll check the next days/weeks if I still see it. This
is a quite long time, at the time of my original bug report, I got the
errors multiple times a day and later multiple times a week.
About the workaround moving to 64 bit OS images: Well, if you're (like
in my case) stuck with dinosaur OS (Windows SBS 2003), there's no way to
simply move to a 64 bit image ;-)
But as said: I think it simply disappeared by some update. I'm using
2.10.0 at the moment.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1307225
Title:
Running a virtual machine on a Haswell system produces machine check
events
Status in QEMU:
Incomplete
Bug description:
I'm running a virtual Windows SBS 2003 installation on a Xeon E3
Haswell system running Gentoo Linux. First, I used Qemu 1.5.3 (the
latest stable version on Gentoo). I got a lot of machine check events
("mce: [Hardware Error]: Machine check events logged") in dmesg that
always looked like (using mcelog):
Hardware event. This is not a software error.
MCE 0
CPU 3 BANK 0
TIME 1397455091 Mon Apr 14 07:58:11 2014
MCG status:
MCi status:
Corrected error
Error enabled
MCA: Internal parity error
STATUS 904f0005 MCGSTATUS 0
MCGCAP c09 APICID 6 SOCKETID 0
CPUID Vendor Intel Family 6 Model 60
I found this discussion on the vmware community:
https://communities.vmware.com/thread/452344
It seems that this is (at least partly) caused by the Qemu machine. I
switched to Qemu 1.7.0, the first version to use "pc-i440fx-1.7". With
this version, the errors almost disappeared, but from time to time, I
still get machine check events. Anyways, they so not seem to affect
neither the vm, nor the host.
The Haswell machine has been set up and running for several days
without a single error message. They only appear when the VM is
running. so I think this is actually some problem with the Haswell
architecture (and not a real hardware error).
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1307225/+subscriptions
Re: [Qemu-devel] [Qemu-block][PATCH] qemu-block: add support HMB with feature commands.
I'll send a patch only when there is a clear real use case. Thanks for your reply. On Mon, Oct 23, 2017 at 11:30 PM, Keith Busch wrote: > On Sat, Oct 21, 2017 at 03:54:16PM +0900, Minwoo Im wrote: >> Add support HMB(Host Memory Block) with feature commands(Get Feature, Set >> Feature). >> nvme-4.14 tree supports HMB features. >> This patch will make nvme controller to return 32MiB preferred size of HMB >> to host via identify command. >> Set Feature, Get Feature implemented for HMB. >> >> Signed-off-by: Minwoo Im > > Nak; this patch doesn't have a use for host memory. It's just advertising > the need without ever accessing it.
Re: [Qemu-devel] [Qemu-block] [PATCH] qemu-block: add support HMB with feature commands.
On Tue, Oct 24, 2017 at 1:18 AM, Stefan Hajnoczi wrote:
> On Sat, Oct 21, 2017 at 03:54:16PM +0900, Minwoo Im wrote:
>> Add support HMB(Host Memory Block) with feature commands(Get Feature, Set
>> Feature).
>> nvme-4.14 tree supports HMB features.
>> This patch will make nvme controller to return 32MiB preferred size of HMB
>> to host via identify command.
>> Set Feature, Get Feature implemented for HMB.
>>
>> Signed-off-by: Minwoo Im
>> ---
>> hw/block/nvme.c | 35 +++
>> hw/block/nvme.h | 21 -
>> 2 files changed, 55 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/block/nvme.c b/hw/block/nvme.c
>> index 6071dc1..d351781 100644
>> --- a/hw/block/nvme.c
>> +++ b/hw/block/nvme.c
>> @@ -605,6 +605,23 @@ static uint16_t nvme_identify(NvmeCtrl *n, NvmeCmd *cmd)
>> }
>> }
>>
>> +static uint32_t nvme_get_feature_hmb(NvmeCtrl *n, NvmeCmd *cmd)
>> +{
>> +uint32_t result = n->hmb_flag.flag;
>> +uint64_t prp1 = le64_to_cpu(cmd->prp1);
>> +uint64_t prp2 = le64_to_cpu(cmd->prp2);
>> +NvmeHmbAttr attr = {0, };
>> +
>> +attr.hsize = cpu_to_le32(n->hmb_attr.hsize);
>> +attr.hmdlal = cpu_to_le32(n->hmb_attr.hmdlal);
>> +attr.hmdlau = cpu_to_le32(n->hmb_attr.hmdlau);
>> +attr.hmdlec = cpu_to_le32(n->hmb_attr.hmdlec);
>> +
>> +nvme_dma_read_prp(n, (uint8_t *)&attr, sizeof(attr), prp1, prp2);
>
> This read can fail if prp1/prp2 are invalid. How should the error be
> reported?
either or both prp1 and prp2 failed, there's no error handling in this code.
agreed it needs to be implemented if this code will be sent as a patch.
>
>> +
>> +return result;
>> +}
>> +
>> static uint16_t nvme_get_feature(NvmeCtrl *n, NvmeCmd *cmd, NvmeRequest
>> *req)
>> {
>> uint32_t dw10 = le32_to_cpu(cmd->cdw10);
>> @@ -617,6 +634,9 @@ static uint16_t nvme_get_feature(NvmeCtrl *n, NvmeCmd
>> *cmd, NvmeRequest *req)
>> case NVME_NUMBER_OF_QUEUES:
>> result = cpu_to_le32((n->num_queues - 1) | ((n->num_queues - 1) <<
>> 16));
>> break;
>> +case NVME_HOST_MEMORY_BUFFER:
>> +result = nvme_get_feature_hmb(n, cmd);
>> +break;
>> default:
>> return NVME_INVALID_FIELD | NVME_DNR;
>> }
>> @@ -625,6 +645,16 @@ static uint16_t nvme_get_feature(NvmeCtrl *n, NvmeCmd
>> *cmd, NvmeRequest *req)
>> return NVME_SUCCESS;
>> }
>>
>> +static void nvme_set_feature_hmb(NvmeCtrl *n, NvmeCmd *cmd)
>> +{
>> +n->hmb_flag.flag = le32_to_cpu(cmd->cdw11);
>> +
>> +n->hmb_attr.hsize = le32_to_cpu(cmd->cdw12);
>> +n->hmb_attr.hmdlal = le32_to_cpu(cmd->cdw13);
>> +n->hmb_attr.hmdlau = le32_to_cpu(cmd->cdw14);
>> +n->hmb_attr.hmdlec = le32_to_cpu(cmd->cdw15);
>> +}
>> +
>> static uint16_t nvme_set_feature(NvmeCtrl *n, NvmeCmd *cmd, NvmeRequest
>> *req)
>> {
>> uint32_t dw10 = le32_to_cpu(cmd->cdw10);
>> @@ -638,6 +668,9 @@ static uint16_t nvme_set_feature(NvmeCtrl *n, NvmeCmd
>> *cmd, NvmeRequest *req)
>> req->cqe.result =
>> cpu_to_le32((n->num_queues - 1) | ((n->num_queues - 1) << 16));
>> break;
>> +case NVME_HOST_MEMORY_BUFFER:
>> +nvme_set_feature_hmb(n, cmd);
>> +break;
>> default:
>> return NVME_INVALID_FIELD | NVME_DNR;
>> }
>> @@ -985,6 +1018,8 @@ static int nvme_init(PCIDevice *pci_dev)
>> id->oacs = cpu_to_le16(0);
>> id->frmw = 7 << 1;
>> id->lpa = 1 << 0;
>> +id->hmpre = 0x2000;
>
> Missing cpu_to_le32()?
agreed hmpre should be set with le32 instead of raw value.
>
>> +id->hmmin = 0x0;
>> id->sqes = (0x6 << 4) | 0x6;
>> id->cqes = (0x4 << 4) | 0x4;
>> id->nn = cpu_to_le32(n->num_namespaces);
>> diff --git a/hw/block/nvme.h b/hw/block/nvme.h
>> index 6aab338..fab748b 100644
>> --- a/hw/block/nvme.h
>> +++ b/hw/block/nvme.h
>> @@ -552,7 +552,10 @@ typedef struct NvmeIdCtrl {
>> uint8_t lpa;
>> uint8_t elpe;
>> uint8_t npss;
>> -uint8_t rsvd511[248];
>> +uint8_t rsvd271[8];
>> +uint32_thmpre;
>> +uint32_thmmin;
>> +uint8_t rsvd511[232];
>> uint8_t sqes;
>> uint8_t cqes;
>> uint16_trsvd515;
>> @@ -623,9 +626,22 @@ enum NvmeFeatureIds {
>> NVME_INTERRUPT_VECTOR_CONF = 0x9,
>> NVME_WRITE_ATOMICITY= 0xa,
>> NVME_ASYNCHRONOUS_EVENT_CONF= 0xb,
>> +NVME_HOST_MEMORY_BUFFER = 0xd,
>> NVME_SOFTWARE_PROGRESS_MARKER = 0x80
>> };
>>
>> +typedef struct NvmeHmbFlag {
>> +uint32_tflag;
>> +} NvmeHmbFlag;
>> +
>> +typedef struct NvmeHmbAttr {
>> +uint32_thsize;
>> +uint32_thmdlal;
>> +uint32_thmdlau;
>> +uint32_thmdlec;
>> +uint8_t rsvd4095[4080];
>> +} NvmeHmbAttr;
>> +
>> typedef struct NvmeRangeType {
>> uint8_t type;
>> uint8_t attributes;
>> @@ -776,6 +792,9 @@ typedef struct NvmeCtrl {
>> uint32_tcmbloc;
>> uint8_t *cmbuf;
>>
>> +
[Qemu-devel] [Bug 1338591] Re: Cursor jumps on shape change with vmware vga
I still reproduce this with QEMU v2.10.0-1649-ga93ece4. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1338591 Title: Cursor jumps on shape change with vmware vga Status in QEMU: Incomplete Bug description: I launch QEMU with the following command line: qemu-system-i386 /home/ruslan/iso/Windoze/qemuxp.img -m 512 -display sdl -vga vmware -enable-kvm The guest OS is Windows XP. To reproduce the problem, do this: 0. Make sure guest is WinXP (don't know if it's really necessary), use vmware VGA 1. Set mouse cursor theme to default black&white theme, i.e. that without any translucency etc. 2. Open a text editor, e.g. built-in notepad 3. Move the cursor inside text entry widget 4. See the cursor jumping away. You basically can't enter the cursor there. This also reproduces with MS Word 2003 even with oxy-white cursor theme (i.e. that with translucency) — seems Word uses its plain black&transparent cursor for I-beam cursor. This doesn't happen with other VGAs, i.e. cirrus and std. I used qemu git master to test this. qemu-system-i386 --version reports version 2.0.90, git describe says v2.1.0-rc0-1-g9d9de25. This also happened in earlier QEMU versions, like 1.5.x and older. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1338591/+subscriptions
[Qemu-devel] [Bug 902720] Re: TIME_MAX not set correctly for OpenBSD in qemu-common.h
Since this bug report was filed OpenBSD has switched from 32-bit time_t to 64-bit time_t on all archs (yes, including 32-bit archs like i386, arm, powerpc). So instead of INT_MAX TIME_MAX should now be set to LLONG_MAX. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/902720 Title: TIME_MAX not set correctly for OpenBSD in qemu-common.h Status in QEMU: Incomplete Bug description: Looking at the OpenBSD buildbot logs I noticed a warning that appears to be a bug in the code. OpenBSD has a 32-bit time_t on all archs at the moment (32-bit and 64-bit). CCi386-softmmu/monitor.o /buildbot-qemu/default_openbsd_current/build/monitor.c: In function 'expire_password': /buildbot-qemu/default_openbsd_current/build/monitor.c:944: warning: overflow in implicit constant conversion qemu-common.h has... #ifndef TIME_MAX #define TIME_MAX LONG_MAX #endif for OpenBSD this should be INT_MAX. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/902720/+subscriptions
[Qemu-devel] [Bug 1728256] [NEW] (Regression) Memory corruption in Windows 10 guest / amd64
Public bug reported: I have a Win 10 Pro x64 guest inside a qemu/kvm running on an Arch x86_64 host. The VM has a physical GPU passed through, as well as the physical USB controllers, as well as a dedicated SSD attached via SATA; you can find the complete libvirt xml here: https://pastebin.com/U1ZAXBNg I built qemu from source using the qemu-minimal-git AUR package; you can find the build script here: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=qemu-minimal-git (if you aren't familiar with Arch, this is essentially a bash script where build() and package() are run to build the files, and then install them into the $pkgdir to later tar them up.) Starting with qemu v2.10.0, Windows crashes randomly with a bluescreen about CRITICAL_STRUCTURE_CORRUPTION. I also tested the git heads f90ea7ba7c, 861cd431c9 and e822e81e35, before I went back to v2.9.0, which is running stable for over 50 hours right now. During my tests I found that locking the memory pages alleviates the problem somewhat, but never completely avoids it. However, with the crashes occuring randomly, that could as well be false conclusions; I had crashes within minutes after boot with that too. I will now start `git bisect`ing; if you have any other suggestions on what I could try or possible patches feel free to leave them with me. ** 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/1728256 Title: (Regression) Memory corruption in Windows 10 guest / amd64 Status in QEMU: New Bug description: I have a Win 10 Pro x64 guest inside a qemu/kvm running on an Arch x86_64 host. The VM has a physical GPU passed through, as well as the physical USB controllers, as well as a dedicated SSD attached via SATA; you can find the complete libvirt xml here: https://pastebin.com/U1ZAXBNg I built qemu from source using the qemu-minimal-git AUR package; you can find the build script here: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=qemu-minimal-git (if you aren't familiar with Arch, this is essentially a bash script where build() and package() are run to build the files, and then install them into the $pkgdir to later tar them up.) Starting with qemu v2.10.0, Windows crashes randomly with a bluescreen about CRITICAL_STRUCTURE_CORRUPTION. I also tested the git heads f90ea7ba7c, 861cd431c9 and e822e81e35, before I went back to v2.9.0, which is running stable for over 50 hours right now. During my tests I found that locking the memory pages alleviates the problem somewhat, but never completely avoids it. However, with the crashes occuring randomly, that could as well be false conclusions; I had crashes within minutes after boot with that too. I will now start `git bisect`ing; if you have any other suggestions on what I could try or possible patches feel free to leave them with me. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1728256/+subscriptions
[Qemu-devel] [Bug 1338591] Re: Cursor jumps on shape change with vmware vga
** Changed in: qemu Status: Incomplete => Triaged -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1338591 Title: Cursor jumps on shape change with vmware vga Status in QEMU: Triaged Bug description: I launch QEMU with the following command line: qemu-system-i386 /home/ruslan/iso/Windoze/qemuxp.img -m 512 -display sdl -vga vmware -enable-kvm The guest OS is Windows XP. To reproduce the problem, do this: 0. Make sure guest is WinXP (don't know if it's really necessary), use vmware VGA 1. Set mouse cursor theme to default black&white theme, i.e. that without any translucency etc. 2. Open a text editor, e.g. built-in notepad 3. Move the cursor inside text entry widget 4. See the cursor jumping away. You basically can't enter the cursor there. This also reproduces with MS Word 2003 even with oxy-white cursor theme (i.e. that with translucency) — seems Word uses its plain black&transparent cursor for I-beam cursor. This doesn't happen with other VGAs, i.e. cirrus and std. I used qemu git master to test this. qemu-system-i386 --version reports version 2.0.90, git describe says v2.1.0-rc0-1-g9d9de25. This also happened in earlier QEMU versions, like 1.5.x and older. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1338591/+subscriptions
[Qemu-devel] [Bug 902720] Re: TIME_MAX not set correctly for OpenBSD in qemu-common.h
** Changed in: qemu Status: Incomplete => Triaged -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/902720 Title: TIME_MAX not set correctly for OpenBSD in qemu-common.h Status in QEMU: Triaged Bug description: Looking at the OpenBSD buildbot logs I noticed a warning that appears to be a bug in the code. OpenBSD has a 32-bit time_t on all archs at the moment (32-bit and 64-bit). CCi386-softmmu/monitor.o /buildbot-qemu/default_openbsd_current/build/monitor.c: In function 'expire_password': /buildbot-qemu/default_openbsd_current/build/monitor.c:944: warning: overflow in implicit constant conversion qemu-common.h has... #ifndef TIME_MAX #define TIME_MAX LONG_MAX #endif for OpenBSD this should be INT_MAX. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/902720/+subscriptions
Re: [Qemu-devel] [PATCH v2] Discover openpty(3) dynamically in configure
On 14.09.2017 15:52, Peter Maydell wrote:
> On 11 September 2017 at 18:16, Kamil Rytarowski wrote:
>> openpty(3) might:
>> - exists in libc (OSX)
>> - exists in libutil (GNU, BSD)
>> - does not exist (SmartOS)
>>
>> Add a function to discover this function in the ./configure script.
>> Add new config types: CONFIG_OPENPTY_LIBC and CONFIG_OPENPTY_LIBUTIL,
>> respectively defined when openpts(3) links with -lc or -lutil.
>>
>> Replace the condition adding -lutil in tests (for openpty(3)) from
>> CONFIG_POSIX to CONFIG_OPENPTY_LIBUTIL.
>>
>> Replace the fallback openpty(3) impelementation comment from Solaris
>> to SmartOS. Solaris is EOL'ed and it's confirmed that it does not work
>> on Oracle Solaris.
>> ---
>> configure | 25 +
>> tests/Makefile.include | 2 +-
>> util/qemu-openpty.c| 4 ++--
>> 3 files changed, 28 insertions(+), 3 deletions(-)
>>
>> diff --git a/configure b/configure
>> index fd7e3a5e81..a614adcd29 100755
>> --- a/configure
>> +++ b/configure
>> @@ -3819,6 +3819,25 @@ EOF
>>fi
>> fi
>>
>> +##
>> +# openpty probe
>> +openpty_libc=no
>> +openpty_libutil=no
>> +cat > $TMPC << EOF
>> +extern int openpty(int *amaster, int *aslave, char *name, void *termp, void
>> *winp);
>
> I think the need to provide a prototype here rather than
> using the system header to define it is revealing that we
> also need a configure test for
> * openpty() in
> * openpty() in
> * openpty() in
>
> Something like this untested code ought to do:
>
> cat > $TMPC << EOF
> #if defined(CONFIG_OPENPTY_IN_PTY_H)
> #include
> #elif defined(CONFIG_OPENPTY_IN_LIBUTIL_H)
> #include
> #elif defined(CONFIG_OPENPTY_IN_UTIL_H)
> #include
> #endif
> int main(void) { return openpty(0, 0, 0, 0, 0); }
> EOF
>
> # Different platforms put openpty() in different headers,
> # and may or may not need us to link against -lutil
> if compile_prog -DCONFIG_OPENPTY_IN_PTY_H ""; then
> openpty_in_pty_h=yes
> elif compile_prog -D_CONFIG_OPENPTY_IN_PTY_H -lutil; then
> openpty_in_pty_h=yes
> openpty_libutil=yes
> elif compile_object -DCONFIG_OPENPTY_IN_LIBUTIL_H; then
> openpty_in_libutil_h=yes
> elif compile_prog -D_CONFIG_OPENPTY_IN_LIBUTIL_H -lutil; then
> openpty_in_libutil_h=yes
> openpty_libutil=yes
> elif compile_object -DCONFIG_OPENPTY_IN_UTIL_H; then
> openpty_in_util_h=yes
> elif compile_prog -D_CONFIG_OPENPTY_IN_UTIL_H -lutil; then
> openpty_in_util_h=yes
> openpty_libutil=yes
> fi
>
> Then in qemu-openpty.c we can do
>
> #include
>
> #if defined(CONFIG_OPENPTY_IN_PTY_H)
> #include
> #elif defined(CONFIG_OPENPTY_IN_LIBUTIL_H)
> #include
> #elif defined(CONFIG_OPENPTY_IN_UTIL_H)
> #include
> #else
> /* sunos fallback code */
> #endif
>
>
>> +if test "$openpty_libc" = "yes" ; then
>> + echo "CONFIG_OPENPTY_LIBC=y" >> $config_host_mak
>> +fi
>
>
> If we use the CONFIG_OPENPTY_IN_*_H constants as above
> we don't need CONFIG_OPENPTY_LIBC any more.
>
> thanks
> -- PMM
>
Hello,
I've naively expected that once a build on a certain OS will be fixed,
it will be functional for longer period (at least few weeks). In one
month qemu has been broken on DragonFly and SmartOS so they are not just
broken in tests, but also in the basic build.
SmartOS has new compatibility problems with grep(1) invocations and tpm
emulator fatal build failure. Few old problems with conflicts with
system headers like conflicts with symbols CS and REG_SP.
There are certainly other small incompatibility problems, after the
breakage. Just a remind that SmartOS was not capable to execute tests
because of incompatible diff(1) invocations and unclear gmake(1)
misbehavior. And this was just the beginning of the problems.
DragonFlyBSD has problems with PAGE_SIZE, PAGE_MASK clash with headers
in s390x code. PAGE_MASK, PAGE_SHIFT and PAGE_SIZE in nand. No single
GTESTER invocation passes.
Because there is need to fix the SmartOS build in order to improve this
openpty(3) patch, I'm resigning from it. I also resign from helping
DragonFly port.
I will focus entirely on the bits that I registered as a maintainer.
I leave the decisions and steps about support of these platforms to
other volunteers and qemu core maintainers.
+ CC Antonio and Peter
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] kvm_intel fails to load on Conroe CPUs running Linux 4.12
On 10.10.2017 16:16, Paolo Bonzini wrote:
On 27/09/2017 21:31, Gerhard Wiesinger wrote:
On 15.09.2017 19:07, Paolo Bonzini wrote:
On 15/09/2017 16:43, Gerhard Wiesinger wrote:
On 27.08.2017 20:55, Paolo Bonzini wrote:
Il 27 ago 2017 4:48 PM, "Gerhard Wiesinger" mailto:li...@wiesinger.com>> ha scritto:
On 27.08.2017 14 :03, Paolo Bonzini wrote:
We will revert the patch, but 4.13.0 will not have the fix.
Expect it in later stable kernels (because vacations).
Thnx. Why will 4.13.0 NOT have the fix?
Because maintainers are on vacation! :-)
Hello Paolo,
Any update on this for 4.12 and 4.13 kernels?
A late fix is better than a wrong fix. Hope to get to it next week!
Hello Paolo,
Any update? Thnx.
Hey, I have a patch now. Any volunteers for testing it?
This is on top of 4.13.
Paolo
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c6ef2940119b..c29bf36485fd 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -200,6 +200,10 @@ struct loaded_vmcs {
int cpu;
bool launched;
bool nmi_known_unmasked;
+ /* Support for vnmi-less CPUs */
+ int soft_vnmi_blocked;
+ ktime_t entry_time;
+ s64 vnmi_blocked_time;
struct list_head loaded_vmcss_on_cpu_link;
};
Hello Paolo,
The patch does not apply, 1st hunk FAILED.
cat arch/x86/kvm/vmx.c.rej
--- arch/x86/kvm/vmx.c
+++ arch/x86/kvm/vmx.c
@@ -200,6 +200,10 @@ struct loaded_vmcs {
int cpu;
bool launched;
bool nmi_known_unmasked;
+ /* Support for vnmi-less CPUs */
+ int soft_vnmi_blocked;
+ ktime_t entry_time;
+ s64 vnmi_blocked_time;
struct list_head loaded_vmcss_on_cpu_link;
};
Tried it to apply against, doesn't look to fit:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/arch/x86/kvm/vmx.c?h=v4.13.10#n197
https://koji.fedoraproject.org/koji/buildinfo?buildID=991441
Will then recompile and test.
Thnx.
Ciao,
Gerhard
[Qemu-devel] [PATCH] oslib-posix: Use sysctl(2) call to resolve exec_dir on NetBSD
NetBSD 8.0(beta) ships with KERN_PROC_PATHNAME in sysctl(2).
Older NetBSD versions can use argv[0] parsing fallback.
This code section is partly shared with FreeBSD.
Signed-off-by: Kamil Rytarowski
---
util/oslib-posix.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/util/oslib-posix.c b/util/oslib-posix.c
index 382bd4a231..77369c92ce 100644
--- a/util/oslib-posix.c
+++ b/util/oslib-posix.c
@@ -49,6 +49,10 @@
#include
#endif
+#ifdef __NetBSD__
+#include
+#endif
+
#include "qemu/mmap-alloc.h"
#ifdef CONFIG_DEBUG_STACK_USAGE
@@ -250,9 +254,14 @@ void qemu_init_exec_dir(const char *argv0)
p = buf;
}
}
-#elif defined(__FreeBSD__)
+#elif defined(__FreeBSD__) \
+ || (defined(__NetBSD__) && defined(KERN_PROC_PATHNAME))
{
+#if defined(__FreeBSD__)
static int mib[4] = {CTL_KERN, KERN_PROC, KERN_PROC_PATHNAME, -1};
+#else
+static int mib[4] = {CTL_KERN, KERN_PROC_ARGS, -1, KERN_PROC_PATHNAME};
+#endif
size_t len = sizeof(buf) - 1;
*buf = '\0';
--
2.14.3
Re: [Qemu-devel] [PATCH v2 1/4] build: allow setting a custom GIT binary for transparent proxying
On Sat, Oct 28, 2017 at 12:53:50PM +1100, Alexey Kardashevskiy wrote:
> On 28/10/17 00:14, Daniel P. Berrange wrote:
> > Some users can't run a bare 'git' command, due to need for a transparent
> > proxying solution such as 'tsocks'. This adds an argument to configure to
> > let users specify such a thing:
> >
> > ./configure --with-git="tsocks git"
> >
> > The submodule script is also updated to give the user a hint about using
> > this
> > flag, if we fail to checkout modules.
> >
> > Signed-off-by: Daniel P. Berrange
> > ---
> > Makefile | 4 ++--
> > configure| 5 +
> > scripts/git-submodule.sh | 30 +-
> > 3 files changed, 32 insertions(+), 7 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 9372742f86..4c9d0eaef2 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -21,14 +21,14 @@ git-submodule-update:
> > ifeq (0,$(MAKELEVEL))
> >git_module_status := $(shell \
> > cd '$(SRC_PATH)' && \
> > -./scripts/git-submodule.sh status $(GIT_SUBMODULES); \
> > +GIT="$(GIT)" ./scripts/git-submodule.sh status $(GIT_SUBMODULES); \
> > echo $$?; \
> >)
> >
> > ifeq (1,$(git_module_status))
> > git-submodule-update:
> > $(call quiet-command, \
> > - (cd $(SRC_PATH) && ./scripts/git-submodule.sh update
> > $(GIT_SUBMODULES)), \
> > + (cd $(SRC_PATH) && GIT="$(GIT)" ./scripts/git-submodule.sh
> > update $(GIT_SUBMODULES)), \
> >"GIT","$(GIT_SUBMODULES)")
> > endif
> > endif
> > diff --git a/configure b/configure
> > index 03547cea6a..65765968f3 100755
> > --- a/configure
> > +++ b/configure
> > @@ -271,6 +271,7 @@ then
> > else
> > git_submodules=""
> > fi
> > +git="git"
> >
> > # Don't accept a target_list environment variable.
> > unset target_list
> > @@ -1294,6 +1295,8 @@ for opt do
> >error_exit "vhost-user isn't available on win32"
> >fi
> >;;
> > + --with-git=*) git="$optarg"
> > + ;;
> >*)
> >echo "ERROR: unknown option $opt"
> >echo "Try '$0 --help' for more information"
> > @@ -5338,6 +5341,7 @@ echo "local state directory queried at runtime"
> > echo "Windows SDK $win_sdk"
> > fi
> > echo "Source path $source_path"
> > +echo "GIT binary$git"
> > echo "GIT submodules$git_submodules"
> > echo "C compiler$cc"
> > echo "Host C compiler $host_cc"
> > @@ -5528,6 +5532,7 @@ echo "extra_cxxflags=$EXTRA_CXXFLAGS" >>
> > $config_host_mak
> > echo "extra_ldflags=$EXTRA_LDFLAGS" >> $config_host_mak
> > echo "qemu_localedir=$qemu_localedir" >> $config_host_mak
> > echo "libs_softmmu=$libs_softmmu" >> $config_host_mak
> > +echo "GIT=$git" >> $config_host_mak
> > echo "GIT_SUBMODULES=$git_submodules" >> $config_host_mak
> >
> > echo "ARCH=$ARCH" >> $config_host_mak
> > diff --git a/scripts/git-submodule.sh b/scripts/git-submodule.sh
> > index 08932a35f0..c66567d409 100755
> > --- a/scripts/git-submodule.sh
> > +++ b/scripts/git-submodule.sh
> > @@ -3,14 +3,19 @@
> > # This code is licensed under the GPL version 2 or later. See
> > # the COPYING file in the top-level directory.
> >
> > -set -e
> > -
> > substat=".git-submodule-status"
> >
> > command=$1
> > shift
> > modules="$@"
> >
> > +test -z "$GIT" && GIT=git
> > +
> > +error() {
> > +printf "$0: %s\n" "$*" >&2
> > +exit 1
> > +}
> > +
> > if test -z "$modules"
> > then
> > test -e $substat || touch $substat
> > @@ -27,12 +32,27 @@ case "$command" in
> > status)
> > test -f "$substat" || exit 1
> > trap "rm -f ${substat}.tmp" EXIT
> > -git submodule status $modules > "${substat}.tmp"
> > +$GIT submodule status $modules > "${substat}.tmp"
> > +test $? -ne 0 && error "failed to query git submodule status"
> > diff "${substat}" "${substat}.tmp" >/dev/null
> > exit $?
> > ;;
> > update)
> > -git submodule update --init $modules 1>/dev/null
> > -git submodule status $modules > "${substat}"
> > +$GIT submodule update --init $modules 1>/dev/null
> > +if test $? -ne 0 ; then
> > +echo
> > +echo "Unable to automatically checkout GIT submodules '$modules'."
> > +echo "If you require use of an alternative GIT binary (for example
> > to"
> > +echo "enable use of a transparent proxy), then please specify it
> > by"
> > +echo "running configure by with the '--with-git' argument. e.g."
> > +echo
> > +echo " $ ./configure --with-git='tsocks git'"
> > +echo
> > +exit 1
> > +fi
> > +$GIT submodule status $modules > "${substat}"
> > +test $? -ne 0 && error "failed to save git submodule status"
>
>
> The way I am testing it - I simply delete .git-submodule-status (I used to
> change it but deleting works as well) and then I get:
>
> ./scripts/git-submodule.sh: 74: ./scripts/git-submodule.sh: cannot create
> .git-submodule-status: Read-only file system
>
> be
[Qemu-devel] [PATCH] smbios: support setting OEM strings table
The cloud-init program currently allows fetching of its data by repurposing of
the 'system' type 'serial' field. This is a clear abuse of the serial field that
would clash with other valid usage a virt management app might have for that
field.
Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to allow
exposing of arbitrary vendor specific strings to the operating system. This is
perfect for use with cloud-init, or as a way to pass arguments to OS installers
such as anaconda.
This patch makes it easier to support this with QEMU. e.g.
$QEMU -smbios type=11,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
It is suggested that any app wanting to make use of this OEM strings capability
for accepting data from the host mgmt layer should use its name as a string
prefix. e.g. to expose OEM strings targetting both cloud init and anaconda in
parallel the mgmt app could set
$QEMU -smbios
type=11,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2:
anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
Use of such string prefixes means the app won't have to care which string slot
its data appears in.
Signed-off-by: Daniel P. Berrange
---
hw/smbios/smbios.c | 72 ++
hw/smbios/smbios_build.h | 12
include/hw/smbios/smbios.h | 6
3 files changed, 90 insertions(+)
diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index 1a5437a07d..5d11f01874 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -96,6 +96,11 @@ static struct {
} type4;
static struct {
+size_t nvalues;
+const char **values;
+} type11;
+
+static struct {
const char *loc_pfx, *bank, *manufacturer, *serial, *asset, *part;
uint16_t speed;
} type17;
@@ -282,6 +287,14 @@ static const QemuOptDesc qemu_smbios_type4_opts[] = {
{ /* end of list */ }
};
+static const QemuOptDesc qemu_smbios_type11_opts[] = {
+{
+.name = "value",
+.type = QEMU_OPT_STRING,
+.help = "OEM string data",
+},
+};
+
static const QemuOptDesc qemu_smbios_type17_opts[] = {
{
.name = "type",
@@ -590,6 +603,27 @@ static void smbios_build_type_4_table(unsigned instance)
smbios_type4_count++;
}
+static void smbios_build_type_11_table(void)
+{
+char count_str[128];
+size_t i;
+
+if (type11.nvalues == 0) {
+return;
+}
+
+SMBIOS_BUILD_TABLE_PRE(11, 0xe00, true); /* required */
+
+snprintf(count_str, sizeof(count_str), "%zu", type11.nvalues);
+t->count = type11.nvalues;
+
+for (i = 0; i < type11.nvalues; i++) {
+SMBIOS_TABLE_SET_STR_LIST(11, type11.values[i]);
+}
+
+SMBIOS_BUILD_TABLE_POST;
+}
+
#define ONE_KB ((ram_addr_t)1 << 10)
#define ONE_MB ((ram_addr_t)1 << 20)
#define ONE_GB ((ram_addr_t)1 << 30)
@@ -832,6 +866,8 @@ void smbios_get_tables(const struct smbios_phys_mem_area
*mem_array,
smbios_build_type_4_table(i);
}
+smbios_build_type_11_table();
+
#define MAX_DIMM_SZ (16ll * ONE_GB)
#define GET_DIMM_SZ ((i < dimm_cnt - 1) ? MAX_DIMM_SZ \
: ((ram_size - 1) % MAX_DIMM_SZ) + 1)
@@ -882,6 +918,38 @@ static void save_opt(const char **dest, QemuOpts *opts,
const char *name)
}
}
+
+struct opt_list {
+const char *name;
+size_t *ndest;
+const char ***dest;
+};
+
+static int save_opt_one(void *opaque,
+const char *name, const char *value,
+Error **errp)
+{
+struct opt_list *opt = opaque;
+
+if (!g_str_equal(name, opt->name)) {
+return 0;
+}
+
+*opt->dest = g_renew(const char *, *opt->dest, (*opt->ndest) + 1);
+(*opt->dest)[*opt->ndest] = value;
+(*opt->ndest)++;
+return 0;
+}
+
+static void save_opt_list(size_t *ndest, const char ***dest,
+ QemuOpts *opts, const char *name)
+{
+struct opt_list opt = {
+name, ndest, dest,
+};
+qemu_opt_foreach(opts, save_opt_one, &opt, NULL);
+}
+
void smbios_entry_add(QemuOpts *opts, Error **errp)
{
const char *val;
@@ -1035,6 +1103,10 @@ void smbios_entry_add(QemuOpts *opts, Error **errp)
save_opt(&type4.asset, opts, "asset");
save_opt(&type4.part, opts, "part");
return;
+case 11:
+qemu_opts_validate(opts, qemu_smbios_type11_opts, &error_fatal);
+save_opt_list(&type11.nvalues, &type11.values, opts, "value");
+return;
[Qemu-devel] [Bug 1728325] [NEW] POWER8: Wrong behaviour with float-to-int punning
Public bug reported:
Building a reduced test program with 'gcc -O2 -fno-inline -mcpu=power8'
produces wrong results at runtime. I don't think gcc is at fault here.
---
#include
int getWord(const float x)
{
return *(int*)&x;
}
void main()
{
int foo = getWord(+123.456f);
int bar = getWord(-123.456f);
printf("%d\n", foo);
printf("%d\n", bar);
return;
}
---
This prints:
---
0
0
---
Compiling with 'gcc -O2 -fno-inline -mcpu=power7' and you instead get the
expected result:
---
1123477881
-1024005767
---
The different between the two programs is:
--- power7.s
+++ power8.s
@@ -6,9 +6,9 @@
.globl getWord
.type getWord, @function
getWord:
- stfs 1,-16(1)
- ori 2,2,0
- lwa 3,-16(1)
+ xscvdpspn 0,1
+ mfvsrwz 3,0
+ extsw 3,3
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size getWord,.-getWord
Seems like qemu doesn't handle xscvdpspn/mfvsrwz correctly.
https://github.com/qemu/qemu/commit/7ee19fb9d682689d36c849576c808cf92e3bae40
https://github.com/qemu/qemu/commit/f5c0f7f981333da59cc35c3210d05ec1775c97c1
** 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/1728325
Title:
POWER8: Wrong behaviour with float-to-int punning
Status in QEMU:
New
Bug description:
Building a reduced test program with 'gcc -O2 -fno-inline
-mcpu=power8' produces wrong results at runtime. I don't think gcc is
at fault here.
---
#include
int getWord(const float x)
{
return *(int*)&x;
}
void main()
{
int foo = getWord(+123.456f);
int bar = getWord(-123.456f);
printf("%d\n", foo);
printf("%d\n", bar);
return;
}
---
This prints:
---
0
0
---
Compiling with 'gcc -O2 -fno-inline -mcpu=power7' and you instead get the
expected result:
---
1123477881
-1024005767
---
The different between the two programs is:
--- power7.s
+++ power8.s
@@ -6,9 +6,9 @@
.globl getWord
.type getWord, @function
getWord:
- stfs 1,-16(1)
- ori 2,2,0
- lwa 3,-16(1)
+ xscvdpspn 0,1
+ mfvsrwz 3,0
+ extsw 3,3
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size getWord,.-getWord
Seems like qemu doesn't handle xscvdpspn/mfvsrwz correctly.
https://github.com/qemu/qemu/commit/7ee19fb9d682689d36c849576c808cf92e3bae40
https://github.com/qemu/qemu/commit/f5c0f7f981333da59cc35c3210d05ec1775c97c1
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1728325/+subscriptions
[Qemu-devel] [Bug 1728325] Re: POWER8: Wrong behaviour with float-to-int punning
I am running:
qemu-ppc64le-static -L /usr/powerpc64le-linux-gnu ./a.out
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1728325
Title:
POWER8: Wrong behaviour with float-to-int punning
Status in QEMU:
New
Bug description:
Building a reduced test program with 'gcc -O2 -fno-inline
-mcpu=power8' produces wrong results at runtime. I don't think gcc is
at fault here.
---
#include
int getWord(const float x)
{
return *(int*)&x;
}
void main()
{
int foo = getWord(+123.456f);
int bar = getWord(-123.456f);
printf("%d\n", foo);
printf("%d\n", bar);
return;
}
---
This prints:
---
0
0
---
Compiling with 'gcc -O2 -fno-inline -mcpu=power7' and you instead get the
expected result:
---
1123477881
-1024005767
---
The different between the two programs is:
--- power7.s
+++ power8.s
@@ -6,9 +6,9 @@
.globl getWord
.type getWord, @function
getWord:
- stfs 1,-16(1)
- ori 2,2,0
- lwa 3,-16(1)
+ xscvdpspn 0,1
+ mfvsrwz 3,0
+ extsw 3,3
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size getWord,.-getWord
Seems like qemu doesn't handle xscvdpspn/mfvsrwz correctly.
https://github.com/qemu/qemu/commit/7ee19fb9d682689d36c849576c808cf92e3bae40
https://github.com/qemu/qemu/commit/f5c0f7f981333da59cc35c3210d05ec1775c97c1
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1728325/+subscriptions
Re: [Qemu-devel] [PATCH v2 1/4] build: allow setting a custom GIT binary for transparent proxying
On 29/10/17 07:45, Daniel P. Berrange wrote:
> On Sat, Oct 28, 2017 at 12:53:50PM +1100, Alexey Kardashevskiy wrote:
>> On 28/10/17 00:14, Daniel P. Berrange wrote:
>>> Some users can't run a bare 'git' command, due to need for a transparent
>>> proxying solution such as 'tsocks'. This adds an argument to configure to
>>> let users specify such a thing:
>>>
>>> ./configure --with-git="tsocks git"
>>>
>>> The submodule script is also updated to give the user a hint about using
>>> this
>>> flag, if we fail to checkout modules.
>>>
>>> Signed-off-by: Daniel P. Berrange
>>> ---
>>> Makefile | 4 ++--
>>> configure| 5 +
>>> scripts/git-submodule.sh | 30 +-
>>> 3 files changed, 32 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/Makefile b/Makefile
>>> index 9372742f86..4c9d0eaef2 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -21,14 +21,14 @@ git-submodule-update:
>>> ifeq (0,$(MAKELEVEL))
>>>git_module_status := $(shell \
>>> cd '$(SRC_PATH)' && \
>>> -./scripts/git-submodule.sh status $(GIT_SUBMODULES); \
>>> +GIT="$(GIT)" ./scripts/git-submodule.sh status $(GIT_SUBMODULES); \
>>> echo $$?; \
>>>)
>>>
>>> ifeq (1,$(git_module_status))
>>> git-submodule-update:
>>> $(call quiet-command, \
>>> - (cd $(SRC_PATH) && ./scripts/git-submodule.sh update
>>> $(GIT_SUBMODULES)), \
>>> + (cd $(SRC_PATH) && GIT="$(GIT)" ./scripts/git-submodule.sh
>>> update $(GIT_SUBMODULES)), \
>>>"GIT","$(GIT_SUBMODULES)")
>>> endif
>>> endif
>>> diff --git a/configure b/configure
>>> index 03547cea6a..65765968f3 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -271,6 +271,7 @@ then
>>> else
>>> git_submodules=""
>>> fi
>>> +git="git"
>>>
>>> # Don't accept a target_list environment variable.
>>> unset target_list
>>> @@ -1294,6 +1295,8 @@ for opt do
>>>error_exit "vhost-user isn't available on win32"
>>>fi
>>>;;
>>> + --with-git=*) git="$optarg"
>>> + ;;
>>>*)
>>>echo "ERROR: unknown option $opt"
>>>echo "Try '$0 --help' for more information"
>>> @@ -5338,6 +5341,7 @@ echo "local state directory queried at runtime"
>>> echo "Windows SDK $win_sdk"
>>> fi
>>> echo "Source path $source_path"
>>> +echo "GIT binary$git"
>>> echo "GIT submodules$git_submodules"
>>> echo "C compiler$cc"
>>> echo "Host C compiler $host_cc"
>>> @@ -5528,6 +5532,7 @@ echo "extra_cxxflags=$EXTRA_CXXFLAGS" >>
>>> $config_host_mak
>>> echo "extra_ldflags=$EXTRA_LDFLAGS" >> $config_host_mak
>>> echo "qemu_localedir=$qemu_localedir" >> $config_host_mak
>>> echo "libs_softmmu=$libs_softmmu" >> $config_host_mak
>>> +echo "GIT=$git" >> $config_host_mak
>>> echo "GIT_SUBMODULES=$git_submodules" >> $config_host_mak
>>>
>>> echo "ARCH=$ARCH" >> $config_host_mak
>>> diff --git a/scripts/git-submodule.sh b/scripts/git-submodule.sh
>>> index 08932a35f0..c66567d409 100755
>>> --- a/scripts/git-submodule.sh
>>> +++ b/scripts/git-submodule.sh
>>> @@ -3,14 +3,19 @@
>>> # This code is licensed under the GPL version 2 or later. See
>>> # the COPYING file in the top-level directory.
>>>
>>> -set -e
>>> -
>>> substat=".git-submodule-status"
>>>
>>> command=$1
>>> shift
>>> modules="$@"
>>>
>>> +test -z "$GIT" && GIT=git
>>> +
>>> +error() {
>>> +printf "$0: %s\n" "$*" >&2
>>> +exit 1
>>> +}
>>> +
>>> if test -z "$modules"
>>> then
>>> test -e $substat || touch $substat
>>> @@ -27,12 +32,27 @@ case "$command" in
>>> status)
>>> test -f "$substat" || exit 1
>>> trap "rm -f ${substat}.tmp" EXIT
>>> -git submodule status $modules > "${substat}.tmp"
>>> +$GIT submodule status $modules > "${substat}.tmp"
>>> +test $? -ne 0 && error "failed to query git submodule status"
>>> diff "${substat}" "${substat}.tmp" >/dev/null
>>> exit $?
>>> ;;
>>> update)
>>> -git submodule update --init $modules 1>/dev/null
>>> -git submodule status $modules > "${substat}"
>>> +$GIT submodule update --init $modules 1>/dev/null
>>> +if test $? -ne 0 ; then
>>> +echo
>>> +echo "Unable to automatically checkout GIT submodules '$modules'."
>>> +echo "If you require use of an alternative GIT binary (for example
>>> to"
>>> +echo "enable use of a transparent proxy), then please specify it
>>> by"
>>> +echo "running configure by with the '--with-git' argument. e.g."
>>> +echo
>>> +echo " $ ./configure --with-git='tsocks git'"
>>> +echo
>>> +exit 1
>>> +fi
>>> +$GIT submodule status $modules > "${substat}"
>>> +test $? -ne 0 && error "failed to save git submodule status"
>>
>>
>> The way I am testing it - I simply delete .git-submodule-status (I used to
>> change it but deleting works as well) and then I get:
>>
>> ./scripts/git-submodule.sh: 74: ./scripts/git-submodule.sh: cannot create
>> .git
Re: [Qemu-devel] [PATCH v4] s390-ccw: print carriage return with new lines
On 27.10.17 18:14, Collin L. Walling wrote:
> The sclp console in the s390 bios writes raw data,
> leading console emulators (such as virsh console) to
> treat a new line ('\n') as just a new line instead
> of as a Unix line feed. Because of this, output
> appears in a "stair case" pattern.
>
> Let's print \r\n on every occurrence of a new line
> in the string passed to write to amend this issue.
>
> This is in sync with the guest Linux code in
> drivers/s390/char/sclp_vt220.c which also does a line feed
> conversion in the console part of the driver.
>
> This fixes the s390-ccw and s390-netboot output like
> $ virsh start test --console
> Domain test started
> Connected to domain test
> Escape character is ^]
> Network boot starting...
> Using MAC address: 02:01:02:03:04:05
> Requesting
> information via DHCP: 010
>
> Signed-off-by: Collin L. Walling
> ---
> pc-bios/s390-ccw/sclp.c | 24 +---
> 1 file changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/pc-bios/s390-ccw/sclp.c b/pc-bios/s390-ccw/sclp.c
> index 486fce1..e6a0898 100644
> --- a/pc-bios/s390-ccw/sclp.c
> +++ b/pc-bios/s390-ccw/sclp.c
> @@ -68,17 +68,35 @@ void sclp_setup(void)
> long write(int fd, const void *str, size_t len)
> {
> WriteEventData *sccb = (void *)_sccb;
> +const char *p = str;
> +size_t data_len = 0;
> +size_t i;
>
> if (fd != 1 && fd != 2) {
> return -EIO;
> }
>
> -sccb->h.length = sizeof(WriteEventData) + len;
> +for (i = 0; i < len; i++) {
> +if ((data_len + 1) >= SCCB_DATA_LEN) {
> +/* We would overflow the sccb buffer, abort early */
> +len = i;
> +break;
> +}
> +
> +if (*p == '\n') {
> +/* Terminal emulators might need \r\n, so generate it */
> +sccb->data[data_len++] = '\r';
> +}
> +
> +sccb->data[data_len++] = *p;
> +p++;
I would probably replace this with str[i] to make it slightly more
readable, but that's just personal preference I think. The resulting
assembly should be identical with any recent compiler.
Reviewed-by: Alexander Graf
Alex
[Qemu-devel] [Qemu devel PATCH] msf2: Wire up SYSRESETREQ in SoC for system reset
Implemented system reset by creating SYSRESETREQ gpio
out from nvic.
Signed-off-by: Subbaraya Sundeep
---
hw/arm/msf2-soc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/hw/arm/msf2-soc.c b/hw/arm/msf2-soc.c
index 6f97fa9..a8ec2cd 100644
--- a/hw/arm/msf2-soc.c
+++ b/hw/arm/msf2-soc.c
@@ -57,6 +57,13 @@ static const int spi_irq[MSF2_NUM_SPIS] = { 2, 3 };
static const int uart_irq[MSF2_NUM_UARTS] = { 10, 11 };
static const int timer_irq[MSF2_NUM_TIMERS] = { 14, 15 };
+static void do_sys_reset(void *opaque, int n, int level)
+{
+if (level) {
+qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET);
+}
+}
+
static void m2sxxx_soc_initfn(Object *obj)
{
MSF2State *s = MSF2_SOC(obj);
@@ -125,6 +132,10 @@ static void m2sxxx_soc_realize(DeviceState *dev_soc, Error
**errp)
error_append_hint(errp, "m3clk can not be zero\n");
return;
}
+
+qdev_connect_gpio_out_named(DEVICE(&s->armv7m.nvic), "SYSRESETREQ", 0,
+qemu_allocate_irq(&do_sys_reset, NULL, 0));
+
system_clock_scale = NANOSECONDS_PER_SECOND / s->m3clk;
for (i = 0; i < MSF2_NUM_UARTS; i++) {
--
2.5.0
