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
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,
On 16 September 2013 17:13, Laszlo Ersek ler...@redhat.com wrote:
H. Normally (as in, virtio-pci), when a VCPU thread (running KVM)
executes guest code that sends data to the host via virtio, KVM kicks
the host notifier eventfd.
What happens in the virtio-pci without eventfd case?
(eg
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:
On 09/17/13 10:09, Peter Maydell wrote:
On 16 September 2013 17:13, Laszlo Ersek ler...@redhat.com wrote:
H. Normally (as in, virtio-pci), when a VCPU thread (running KVM)
executes guest code that sends data to the host via virtio, KVM kicks
the host notifier eventfd.
What happens in
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
On 09/17/13 11:51, Richard Jones wrote:
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
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
On 09/16/13 16:39, Richard Jones wrote:
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.
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:
** 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
14 matches
Mail list logo
