** 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/1657010
Title:
RFE: Please implement -cpu best or a CPU fallback option
Status in QEMU:
The logic in util/qemu-sockets.c is very complicated, containing workarounds
for all sorts of broken/obsolete GAI implementations, so it's hard to tell
what's going on there.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
ping6 output when the network is not connected:
$ ping6 ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.082 ms
64 bytes from ::1: icmp_seq=2 ttl=64 time=0.092 ms
64 bytes from ::1: icmp_seq=3 ttl=64 time=0.089 ms
^C
--- ::1 ping statistics ---
3 packets transmitted, 3
ip output when the network is not connected:
$ ip a show scope host
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128
Public bug reported:
I'm not sure if this is a qemu thing or a getaddrinfo/glibc thing, or
even just something about my laptop. However we have a test failure
in nbdkit which only occurs when my laptop is not connected to wifi or
other networking. It boils down to:
$ qemu-img info
Kevin suggested this change, which works for me:
diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
index 6eb258d3f3..0e9027c8f3 100644
--- a/hw/scsi/scsi-disk.c
+++ b/hw/scsi/scsi-disk.c
@@ -482,7 +482,7 @@ static bool scsi_handle_rw_error(SCSIDiskReq *r, int error,
bool acct_failed)
Public bug reported:
Reported downstream in Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1650975
Using qemu from git and reasonably recent nbdkit, this command injects -EIO
errors into the block device which virtio-scsi is reading from:
$ nbdkit --filter=error memory size=64M
Fixed upstream in
https://github.com/libguestfs/libguestfs/commit/f00f920ad3b15ab8e9e8f201c16e7628b6b7b109
The fix should appear in libguestfs 1.40.
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which
Sorry I noticed this bug is filed against qemu. The fix was done in
libguestfs, it's not a bug in qemu as far as I know.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1740364
Title:
qemu-img:
I suspect this bug is probably still around, and if not then this class
of bugs is certainly still around. What we have done in management
tools like Open Stack is to confine qemu-img using simple ulimits when
inspecting any untrusted image, and that solves the problem so it's
probably fine to
Let's close this. libguestfs doesn't use snapshot=on any longer.
** Changed in: qemu
Status: In Progress => 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/1155677
Title:
The answer is I don't know. Closing this bug seems correct unless
someone can reproduce the original problem.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1186984
Title:
large -initrd can wrap
I restored the original description. Please report a new bug.
** Description changed:
+
I have a remote server, on which an http disk image definitely exists.
- However the qemu curl block driver cannot open it. It always gives the
+ However the qemu curl block driver cannot open it. It
cmd, "info");
+ guestfs_int_cmd_add_arg (cmd, "-U");
guestfs_int_cmd_add_arg (cmd, "--output");
guestfs_int_cmd_add_arg (cmd, "json");
guestfs_int_cmd_add_arg (cmd, fdpath);
Rich.
--
Richard Jones, Virtualization Group, Red Hat ht
Yes, qemu's working fine on aarch64 so this must have been fixed.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1378554
Title:
qemu segfault in virtio_scsi_handle_cmd_req_submit on ARM 32 bit
Oh yes, long fixed.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1383857
Title:
aarch64: virtio disks don't show up in guest (neither blk nor scsi)
Status in QEMU:
Incomplete
Bug description:
Closed it, very old bug and we successfully test many disks with
ppc64/le nowadays.
** Changed in: qemu
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1013691
Public bug reported:
Typing the literal command ‘qemu-img info replication:’ causes a
segfault. Note that ‘replication:’ is not a filename.
$ ./qemu-img info replication:
qemu-img: block.c:2609: bdrv_open_inherit: Assertion `!!(flags &
BDRV_O_PROTOCOL) == !!drv->bdrv_file_open' failed.
Aborted
minimally
required a Pentium processor (and 16 MB of RAM :-)
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside th
Public bug reported:
Grab the NT 4 disk from
https://archive.org/details/Microsoft_Windows_NT_Server_Version_4.0_227-075
-385_CD-KEY_419-1343253_1996
Try to boot it as follows:
qemu-system-x86_64 -hda disk.img -cdrom
Public bug reported:
qemu runs very slowly when adding many virtio-scsi drives. I have
attached a small reproducer shell script which demonstrates this.
Using perf shows the following stack trace taking all the time:
72.42%71.15% qemu-system-x86 qemu-system-x86_64 [.] drive_get
Public bug reported:
$ qemu-system-x86_64 -drive file=/tmp/foo\" -writeconfig -
# qemu config file
[drive]
file = "/tmp/foo""
For bonus points, try to construct a valid qemu config file that
contains a quoted value. It's pretty clear (from looking at the code
also) that this is not possible.
I don't know how to close bugs in launchpad, but this one can be closed
for a couple of reasons:
(1) I benchmarked virtio-mmio the other day using qemu-speed-test on aarch64
and I did not encounter the bug.
(2) aarch64 has supported virtio-pci for a while, for virtio-mmio is effectively
Fixed upstream, see previous comment.
** 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/122
Title:
virtio-serial loses writes when used over
Public bug reported:
QEMU should implement a -cpu best option or some other way to make this
work:
qemu -M pc,accel=kvm:tcg -cpu best
qemu -M pc,accel=kvm:tcg -cpu host:qemu64
See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1277744#c6
** Affects: qemu
Importance: Undecided
No this refers to a very old version of qemu. This bug should be
closed.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649
Title:
qemu 1.1.0 waits for a keypress at boot
Status in QEMU:
I sent a patch to qemu-devel which should fix this.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1470536
Title:
qemu-img incorrectly prints qemu-img: Host floppy pass-through is
deprecated
Public bug reported:
qemu-img incorrectly prints this warning when you use /dev/fd/NN to
pass in file descriptors. A simple way to demonstrate this uses bash
process substitution, so the following will only work if you are using
bash as your shell:
$ qemu-img info ( cat /dev/null )
qemu-img:
This slightly modified example takes about 7 seconds and 2 GB of heap:
$ /usr/bin/time ~/d/qemu/qemu-img info /mnt/scratch/afl13.img
block-vpc: The header checksum of '/mnt/scratch/afl13.img' is incorrect.
qemu-img: Could not open '/mnt/scratch/afl13.img': block-vpc:
free_data_block_offset
Both files were found by using american-fuzzy-lop.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1462949
Title:
vmdk files cause qemu-img to consume lots of time and memory
Status in QEMU:
New
** Attachment added: afl11.img
https://bugs.launchpad.net/qemu/+bug/1462949/+attachment/4411476/+files/afl11.img
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1462949
Title:
vmdk files cause
Public bug reported:
The two attached files cause 'qemu-img info' to consume lots of time and
memory. Around 10-12 seconds of CPU time, and around 3-4 GB of heap.
$ /usr/bin/time ~/d/qemu/qemu-img info afl10.img
qemu-img: Can't get size of device 'image': File too large
0.40user 11.57system
Public bug reported:
The attached vpc file causes 'qemu-img info' to consume 3 or 4 seconds
of CPU time and 1.3 GB of heap, causing a minor denial of service.
$ /usr/bin/time ~/d/qemu/qemu-img info afl12.img
block-vpc: The header checksum of 'afl12.img' is incorrect.
qemu-img: Could not open
Although the error message is the same, the bug in comment 5 seems
completely different. Please open a new bug about this issue, giving
*all* details - including the full qemu command line.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to
Still happening with latest upstream kernel. It seems to involve using
the -initrd option at all, with any cpio file, even a tiny one. More
results posted here:
https://lists.cs.columbia.edu/pipermail/kvmarm/2014-December/012557.html
--
You received this bug notification because you are a
Finally found the problem, patch posted:
https://lists.gnu.org/archive/html/qemu-devel/2014-12/msg00034.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1383857
Title:
aarch64: virtio disks
Finally finished the git bisect (of the guest kernel, not qemu):
421520ba98290a73b35b7644e877a48f18e06004 is the first bad commit
commit 421520ba98290a73b35b7644e877a48f18e06004
Author: Yalin Wang yalin.w...@sonymobile.com
Date: Fri Sep 26 03:07:09 2014 +0100
ARM: 8167/1: extend the
Public bug reported:
kernel-3.18.0-0.rc1.git0.1.rwmj5.fc22.aarch64 (3.18 rc1 + some hardware
enablement)
qemu from git today
When I create a guest with virtio-scsi disks, they don't show up inside the
guest.
Literally after the virtio_mmio.ko and virtio_scsi.ko modules are loaded, there
are
I have now also tried virtio-blk and that doesn't work either. Same
symptoms: no log messages at all (even with ignore_loglevel), and no
disks appear.
Yeah, regressed with this newer kernel sounds more like a kernel
bug than a QEMU bug to me, especially if all the other virt devices
still
This is qemu from git today (2014-10-07).
The hardware is 32 bit ARM (ODROID-XU Samsung Exynos 5410). It is
running Ubuntu 14.04 LTS as the main operating system, but I am NOT
using qemu from Ubuntu (which is ancient).
--
You received this bug notification because you are a member of qemu-
Public bug reported:
/home/rjones/d/qemu/arm-softmmu/qemu-system-arm \
-global virtio-blk-device.scsi=off \
-nodefconfig \
-enable-fips \
-nodefaults \
-display none \
-M virt \
-machine accel=kvm:tcg \
-m 500 \
-no-reboot \
-rtc driftfix=slew \
-global
FWIW I am able to reproduce this quite easily on aarch64 too.
My test program is:
https://github.com/libguestfs/libguestfs/blob/master/tests/qemu/qemu-speed-test.c
and you use it like this:
qemu-speed-test --virtio-serial-upload
(You can also test virtio-serial downloads and a few other things,
Turns out this is because of using snapshot=on.
Simple reproducer:
./x86_64-softmmu/qemu-system-x86_64 -drive
'file=http://127.0.0.1/~rjones/cirros-0.3.1-x86_64-disk.img,if=virtio,snapshot=on'
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed
Public bug reported:
I have a remote server, on which an http disk image definitely exists.
However the qemu curl block driver cannot open it. It always gives the
bogus error:
CURL: Error opening file: Connection time-out
qemu-system-x86_64: -drive
Public bug reported:
Note this is using the not-yet-upstream aarch64 patches from:
https://github.com/susematz/qemu/tree/aarch64-1.6
This binary:
http://oirase.annexia.org/tmp/test.gz
runs OK on real aarch64 hardware. It is a statically linked Linux
binary which (if successful)
It's an Aarch64 binary so it won't run on 32 bit ARM at all. However I
guess you meant does the equivalent program run on 32 bit ARM, and the
answer is yes, but that doesn't tell us much because OCaml uses separate
code generators for 32 and 64 bit ARM.
The binary is single threaded.
I enabled
One thing I notice is that caml_c_call is the only function that uses
the instruction ret xM (in all other places the code uses the default
ret with implicit x30). Hmmm .. do we emulate ret xM?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed
The attached patch fixes the ret xM variant of ret. I verified that it
fixes the bug.
** Patch added: 0001-arm64-Set-source-for-ret-instruction-correctly.patch
https://bugs.launchpad.net/qemu/+bug/1263747/+attachment/3934836/+files/0001-arm64-Set-source-for-ret-instruction-correctly.patch
What happens if you add a five second delay to libguestfs,
before writing the response?
No change. Still hangs in the same place.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/122
Title:
There's at least three cases here I guess (KVM + eventfd, KVM without
eventfd (enforceable eg. with the ioeventfd property for virtio
devices), and TCG). We're probably talking about the third case.
To clarify on this point: I have reproduced this bug on two different ARM
machines, one using
Is this a socket that libguestfs pre-creates on the host-side?
Yes it is:
https://github.com/libguestfs/libguestfs/blob/master/src/launch-direct.c#L208
You mention a scenario that might cause this. But that appears to be
when the socket is opened. Note that the guest did send 4 bytes
I can reproduce this bug on a second ARM machine which doesn't have KVM
(ie. using TCG). Note it's still linked to virtio-mmio.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/122
Title:
Public bug reported:
virtio-serial appears to lose writes, but only when used on top of
virtio-mmio. The scenario is this:
/home/rjones/d/qemu/arm-softmmu/qemu-system-arm \
-global virtio-blk-device.scsi=off \
-nodefconfig \
-nodefaults \
-nographic \
-M vexpress-a15 \
** Description changed:
virtio-serial appears to lose writes, but only when used on top of
virtio-mmio. The scenario is this:
/home/rjones/d/qemu/arm-softmmu/qemu-system-arm \
-global virtio-blk-device.scsi=off \
-nodefconfig \
-nodefaults \
-nographic \
-M
Recall this bug only happens intermittently. This is an strace -f of
qemu when it happens to work.
Notes:
- fd = 6 is the Unix domain socket
- there are an expected number of recvmsg writes, all with the correct sizes
- this time qemu adds the socket to ppoll
** Attachment added: working
strace -f of qemu when it fails.
Notes:
- fd = 6 is the Unix domain socket connected to virtio-serial
- only one 4 byte write occurs to this socket (expected guest - host
communication)
- the socket isn't read at all (even though the library on the other side has
written)
- the socket is
Public bug reported:
NB: This bug ONLY happens on i686. When qemu is compiled for x86-64,
the bug does NOT happen.
$ ./configure --enable-tpm
$ make
$ (sleep 5; printf
'{execute:qmp_capabilities}\n{execute:query-tpm-types}\n') |
./i386-softmmu/qemu-system-i386 -S -nodefaults -nographic -M
Public bug reported:
Download a Fedora 19 ISO from:
http://mirrors.kernel.org/fedora-secondary/releases/19/Fedora/ppc64/iso/
Compile qemu from git (I'm using 401c227b0a1134245ec61c6c5a9997cfc963c8e4
from today).
Run qemu-system-ppc64 like this:
ppc64-softmmu/qemu-system-ppc64 -M pseries -m
** Description changed:
Download a Fedora 19 ISO from:
http://mirrors.kernel.org/fedora-secondary/releases/19/Fedora/ppc64/iso/
Compile qemu from git (I'm using 401c227b0a1134245ec61c6c5a9997cfc963c8e4
from today).
Run qemu-system-ppc64 like this:
git bisect points the finger at:
401c227b0a1134245ec61c6c5a9997cfc963c8e4 is the first bad commit
commit 401c227b0a1134245ec61c6c5a9997cfc963c8e4
Author: Richard Henderson r...@twiddle.net
Date: Thu Jul 25 07:16:52 2013 -1000
tcg-i386: Use new return-argument ld/st helpers
** Description changed:
I have Windows XP SP3 inside qemu VM. All works fine in 12.10. But
after upgraiding to 13.04 i have to restart the VM each time i resuming
my host machine, because qemu process starts to take CPU cycles and OS
inside VM is very slow and sluggish. However it's
I'm using qemu from git (f10acc8b38d65a66ffa0588a036489d7fa6a593e).
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1186984
Title:
large -initrd crashes qemu
Status in QEMU:
New
Bug description:
Public bug reported:
We don't use large -initrd in libguestfs any more, but I noticed that a
large -initrd file now crashes qemu spectacularly:
$ ls -lh /tmp/kernel /tmp/initrd
-rw-r--r--. 1 rjones rjones 273M Jun 3 14:02 /tmp/initrd
lrwxrwxrwx. 1 rjones rjones 35 Jun 3 14:02 /tmp/kernel -
One way to reproduce this is to just use a large (200 MB) completely
random initrd. Note this error seems to happen a long time before even
the kernel starts up, so the actual content of the initrd doesn't
matter.
dd if=/dev/urandom of=/tmp/initrd bs=1M count=200
qemu-system-x86_64 -kernel
OK I see what's happening. Because I forgot about the -m option, qemu
allocates 128 MB of RAM. It's obviously wrapping around in memory and
overwriting all the low memory.
If you add (eg) -m 1024 it works.
--
You received this bug notification because you are a member of qemu-
devel-ml, which
** Summary changed:
- large -initrd crashes qemu
+ large -initrd can wrap around in memory causing memory corruption
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1186984
Title:
large -initrd can
Simple reproducer using only qemu tools:
$ qemu-img create -f qcow2 huge.qcow2 $((1024*1024))T
Formatting 'huge.qcow2', fmt=qcow2 size=1152921504606846976 encryption=off
cluster_size=65536 lazy_refcounts=off
$ qemu-io /tmp/huge.qcow2 -c write $((1024*1024*1024*1024*1024*1024 - 1024))
512
Still happening in upstream qemu from git:
Program terminated with signal 11, Segmentation fault.
#0 0x7f4f86c721a0 in get_cluster_table (bs=bs@entry=0x7f4f886e7880,
offset=offset@entry=1152921504606834688,
new_l2_table=new_l2_table@entry=0x7f4f8ad9a0b0,
Thanks for the detailed test case and fix. However unfortunately I cannot see
d6e839e718 in the current qemu git. Is it possible the commit hash changed
because of a rebase when it was committed?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
Thanks - fix committed to Fedora. Hopefully this will squash the rare
and random segfaults in the libguestfs test suite.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1127369
Title:
i386
Public bug reported:
The snapshot=on option doesn't work with an nbd block device:
/usr/bin/qemu-system-x86_64 \
[...]
-device virtio-scsi-pci,id=scsi \
-drive file=nbd:localhost:61930,snapshot=on,format=raw,id=hd0,if=none \
-device scsi-hd,drive=hd0 \
[...]
gives the error:
71 matches
Mail list logo
