From: "Laszlo Ersek \(Red Hat\)" <lersek@redhat.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Bug 1224444] [NEW] virtio-serial loses writes when used over virtio-mmio
Date: Mon, 16 Sep 2013 14:27:15 -0000 [thread overview]
Message-ID: <523715B1.9020008@redhat.com> (raw)
In-Reply-To: 20130912120415.31262.22076.malonedeb@chaenomeles.canonical.com
On 09/12/13 14:04, Richard Jones wrote:
> + -chardev
socket,path=/home/rjones/d/libguestfs/tmp/libguestfsLa9dE2/guestfsd.sock,id=channel0
\
Is this a socket that libguestfs pre-creates on the host-side?
> the socket is never added to any poll/ppoll syscall, so it's no
> wonder that qemu never sees any data on the socket
This should be happening:
qemu_chr_open_socket() [qemu-char.c]
unix_connect_opts() [util/qemu-sockets.c]
qemu_socket()
connect()
qemu_set_nonblock() [util/oslib-posix.c]
qemu_chr_open_socket_fd()
socket_set_nodelay() [util/osdep.c]
io_channel_from_socket()
g_io_channel_unix_new()
tcp_chr_connect()
io_add_watch_poll()
g_source_new()
g_source_attach()
g_source_unref()
qemu_chr_be_generic_open()
io_add_watch_poll() should make sure the fd is polled starting with the
next main loop iteration.
Interestingly, even in the "successful" case, there's a slew of ppoll()
calls between connect() returning 6, and the first ppoll() that actually
covers fd=6.
Laszlo
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1224444
Title:
virtio-serial loses writes when used over virtio-mmio
Status in QEMU:
New
Bug description:
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 \
-machine accel=kvm:tcg \
-m 500 \
-no-reboot \
-kernel /home/rjones/d/libguestfs/tmp/.guestfs-1001/kernel.27944 \
-dtb /home/rjones/d/libguestfs/tmp/.guestfs-1001/dtb.27944 \
-initrd /home/rjones/d/libguestfs/tmp/.guestfs-1001/initrd.27944 \
-device virtio-scsi-device,id=scsi \
-drive file=/home/rjones/d/libguestfs/tmp/libguestfsLa9dE2/scratch.1,cache=unsafe,format=raw,id=hd0,if=none \
-device scsi-hd,drive=hd0 \
-drive file=/home/rjones/d/libguestfs/tmp/.guestfs-1001/root.27944,snapshot=on,id=appliance,cache=unsafe,if=none \
-device scsi-hd,drive=appliance \
-device virtio-serial-device \
-serial stdio \
-chardev socket,path=/home/rjones/d/libguestfs/tmp/libguestfsLa9dE2/guestfsd.sock,id=channel0 \
-device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \
-append 'panic=1 mem=500M console=ttyAMA0 udevtimeout=600 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color'
After the guest starts up, a daemon writes 4 bytes to a virtio-serial
socket. The host side reads these 4 bytes correctly and writes a 64
byte message. The guest never sees this message.
I enabled virtio-mmio debugging, and this is what is printed (## = my
comment):
## guest opens the socket:
trying to open virtio-serial channel '/dev/virtio-ports/org.libguestfs.channel.0'
virtio_mmio: virtio_mmio_write offset 0x50 value 0x3
opened the socket, sock = 3
udevadm settle
## guest writes 4 bytes to the socket:
virtio_mmio: virtio_mmio_write offset 0x50 value 0x5
virtio_mmio: virtio_mmio setting IRQ 1
virtio_mmio: virtio_mmio_read offset 0x60
virtio_mmio: virtio_mmio_write offset 0x64 value 0x1
virtio_mmio: virtio_mmio setting IRQ 0
sent magic GUESTFS_LAUNCH_FLAG
## host reads 4 bytes successfully:
main_loop libguestfs: recv_from_daemon: received GUESTFS_LAUNCH_FLAG
libguestfs: [14605ms] appliance is up
Guest launched OK.
## host writes 64 bytes to socket:
libguestfs: writing the data to the socket (size = 64)
waiting for next request
libguestfs: data written OK
## hangs here forever with guest in read() call never receiving any data
I am using qemu from git today (2d1fe1873a984).
Some notes:
- It's not 100% reproducible. Sometimes everything works fine, although it fails "often" (eg > 2/3rds of the time).
- KVM is being used.
- We've long used virtio-serial on x86 and have never seen anything like this.
This is what the output looks like when it doesn't fail:
trying to open virtio-serial channel '/dev/virtio-ports/org.libguestfs.channel.0
'
virtio_mmio: virtio_mmio_write offset 0x50 value 0x3
opened the socket, sock = 3
udevadm settle
virtio_mmio: virtio_mmio_write offset 0x50 value 0x5
virtio_mmio: virtio_mmio setting IRQ 1
virtio_mmio: virtio_mmio_read offset 0x60
virtio_mmio: virtio_mmio_write offset 0x64 value 0x1
virtio_mmio: virtio_mmio setting IRQ 0
sent magic GUESTlibguestfs: recv_from_daemon: received GUESTFS_LAUNCH_FLAG
libguestfs: [14710ms] appliance is up
Guest launched OK.
libguestfs: writing the data to the socket (size = 64)
FS_LAUNCH_FLAG
main_loop waiting for next request
libguestfs: data written OK
virtio_mmio: virtio_mmio_write offset 0x50 value 0x2
virtio_mmio: virtio_mmio setting IRQ 1
virtio_mmio: virtio_mmio setting IRQ 1
virtio_mmio: virtio_mmio_write offset 0x50 value 0x2
virtio_mmio: virtio_mmio_read offset 0x60
virtio_mmio: virtio_mmio setting IRQ 1
virtio_mmio: virtio_mmio_write offset 0x64 value 0x1
virtio_mmio: virtio_mmio setting IRQ 0
virtio_mmio: virtio_mmio_read offset 0x60
virtio_mmio: virtio_mmio_write offset 0x64 value 0x0
virtio_mmio: virtio_mmio setting IRQ 0
virtio_mmio: virtio_mmio_read offset 0x60
virtio_mmio: virtio_mmio_write offset 0x64 value 0x1
[... more virtio-mmio lines omitted ...]
virtio_mmio: virtio_mmio_write offset 0x64 value 0x0
virtio_mmio: virtio_mmio setting IRQ 1
virtio_mmio: virtio_mmio_read offset 0x60
virtio_mmio: virtio_mmio_write offset 0x64 value 0x1
virtio_mmio: virtio_mmio setting IRQ 0
guestfsd: main_loop: new request, len 0x3c
virtio_mmio: virtio_mmio_write offset 0x50 value 0x4
0000: 20 00 f5 f5 00 00 00 04 00 00 00 d2 00 00 00 00 | ...............|virtio_mmio: virtio_mmio_write offset 0x50 value 0x2
virtio_mmio: virtio_mmio setting IRQ 1
virtio_mmio: virtio_mmio_read offset 0x60
virtio_mmio: virtio_mmio_write offset 0x64 value 0x1
virtio_mmio: virtio_mmio setting IRQ 0
0010: 00 12 34 00 00 00 00 00 00 00 00 00 00 00 00 00 |..4.............|
0020: 00 00 00 00 00 00 00 00 00 00 00 08 2f 64 65 76 |............/dev|
0030: 2f 73 64 61 00 00 00 03 6d 62 72 00 |/sda....mbr. |
virtio_mmio: virtio_mmio_write offset 0x50 value 0x2
virtio_mmio: virtio_mmio setting IRQ 1
virtio_mmio: virtio_mmio_read offset 0x60
virtio_mmio: virtio_mmio_write offset 0x64 value 0x1
virtio_mmio: virtio_mmio setting IRQ 0
virtio_mmio: virtio_mmio_write offset 0x50 value 0x2
virtio_mmio: virtio_mmio setting IRQ 1
virtio_mmio: virtio_mmio_read offset 0x60
virtio_mmio: virtio_mmio_write offset 0x64 value 0x1
virtio_mmio: virtio_mmio setting IRQ 0
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1224444/+subscriptions
next prev parent reply other threads:[~2013-09-16 14:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-12 12:04 [Qemu-devel] [Bug 1224444] [NEW] virtio-serial loses writes when used over virtio-mmio Richard Jones
2013-09-12 12:55 ` [Qemu-devel] [Bug 1224444] " Richard Jones
2013-09-12 14:33 ` Richard Jones
2013-09-12 14:38 ` Richard Jones
2013-09-14 5:53 ` Richard Jones
2013-09-16 14:27 ` Laszlo Ersek (Red Hat) [this message]
2013-09-16 14:39 ` Richard Jones
2013-09-16 16:12 ` Laszlo Ersek (Red Hat)
2013-09-17 8:09 ` Peter Maydell
2013-09-17 9:45 ` Laszlo Ersek (Red Hat)
2013-09-17 8:17 ` Richard Jones
2013-09-17 9:51 ` Richard Jones
2013-09-17 16:54 ` Laszlo Ersek (Red Hat)
2014-07-29 11:37 ` Richard Jones
2017-03-04 14:07 ` Richard Jones
2017-03-04 14:08 ` Richard Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=523715B1.9020008@redhat.com \
--to=lersek@redhat.com \
--cc=1224444@bugs.launchpad.net \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.