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
obsolete.
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 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
> 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 usi
On 09/17/13 10:09, Peter Maydell wrote:
> On 16 September 2013 17:13, Laszlo Ersek 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 virti
> 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 16 September 2013 17:13, Laszlo Ersek 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 virtio-pci on a n
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 o
> 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
successf
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:
virtio-
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 n
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
** 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
14 matches
Mail list logo