All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.