qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Antonios Motakis <a.motakis@virtualopensystems.com>
Cc: Luke Gorrie <lukego@gmail.com>,
	"snabb-devel@googlegroups.com" <snabb-devel@googlegroups.com>,
	Nikolay Nikolaev <n.nikolaev@virtualopensystems.com>,
	qemu-devel qemu-devel <qemu-devel@nongnu.org>,
	VirtualOpenSystems Technical Team <tech@virtualopensystems.com>
Subject: Re: [Qemu-devel] [PATCH v9 10/20] Gracefully handle ioctl failure in vhost_virtqueue_stop
Date: Wed, 5 Mar 2014 15:47:31 +0200	[thread overview]
Message-ID: <20140305134731.GA25484@redhat.com> (raw)
In-Reply-To: <CAG8rG2yxzdBPAMPS9oqaaTxTgfrccodzRXWKsDg-uH92ZWzgKA@mail.gmail.com>

On Wed, Mar 05, 2014 at 02:38:34PM +0100, Antonios Motakis wrote:
> Hello,
> 
> 
> On Tue, Mar 4, 2014 at 7:45 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> 
>     On Tue, Mar 04, 2014 at 07:22:53PM +0100, Antonios Motakis wrote:
>     > On stopping the vhost, a call to VHOST_GET_VRING_BASE is issued. The
>     > received value is stored as last_avail_idx, so the virtqueue can continue
>     > operating if the connection is resumed. Handle the failure of this call
>     > and use the current avail_idx. Some packets from the avail ring may be
>     > omitted but still we keep a sane value and can continue on reconnect.
> 
>     omitted how?
>     some guests crash if we never complete handling buffers,
>     or networking breaks, etc ...
> 
>     This would be a big problem for reconnect, some robust way to
>     communicate avail ring state would need to be found.
>     Is reconnect really a mandatory feature for you?
>     I'd suggest you drop it from v1, focus on basic functionality.
> 
> 
> 
> Reconnect would be a really useful feature for us, so we tried to keep it in a
> reasonable way.
> 
> However we didn't take into account that some guests might crash under those
> assumptions. Looks like we have no option but to remove reconnect altogether
> for now; maybe a future extension to the virtio-net spec will allow us to do it
> cleanly, but I don't see an obvious workaround to keep this in now.
> 
> Thanks for pointing this out.
> 
> Btw, since it looks like we are closing a final version of the patches, what
> kind of timeframe should we aim for inclusion? Should we already rebase on top
> of Paolo's NUMA patch series?
> 

I think it should be possible to merge after Paolo's
patches go in, yes. I haven't followed them closely
so I don't know when will that be.

I wish someone else would ack the char dev changes - anyone?
But it's not a blocker requirement.


>     >
>     > Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
>     > Signed-off-by: Nikolay Nikolaev <n.nikolaev@virtualopensystems.com>
> 
>     Problem is, a bunch of stuff breaks if vhost keeps
>     going when we ask it to stop.
>     In particular it will keep looking at the ring
>     state when guest asked it to stop doing this,
>     this will corrupt guest memory.
> 
> 
>     > ---
>     >  hw/virtio/vhost.c | 3 ++-
>     >  1 file changed, 2 insertions(+), 1 deletion(-)
>     >
>     > diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
>     > index 9e336ad..322e2c0 100644
>     > --- a/hw/virtio/vhost.c
>     > +++ b/hw/virtio/vhost.c
>     > @@ -758,12 +758,13 @@ static void vhost_virtqueue_stop(struct vhost_dev
>     *dev,
>     >      assert(idx >= dev->vq_index && idx < dev->vq_index + dev->nvqs);
>     >      r = ioctl(dev->control, VHOST_GET_VRING_BASE, &state);
>     >      if (r < 0) {
>     > +        state.num = virtio_queue_get_avail_idx(vdev, idx);
>     >          fprintf(stderr, "vhost VQ %d ring restore failed: %d\n", idx,
>     r);
>     >          fflush(stderr);
>     >      }
>     >      virtio_queue_set_last_avail_idx(vdev, idx, state.num);
>     >      virtio_queue_invalidate_signalled_used(vdev, idx);
>     > -    assert (r >= 0);
>     > +
>     >      cpu_physical_memory_unmap(vq->ring, virtio_queue_get_ring_size(vdev,
>     idx),
>     >                                0, virtio_queue_get_ring_size(vdev, idx));
>     >      cpu_physical_memory_unmap(vq->used, virtio_queue_get_used_size(vdev,
>     idx),
>     > --
>     > 1.8.3.2
> 
> 
> 
> 
> --
> Antonios Motakis
> Virtual Open Systems

  reply	other threads:[~2014-03-05 13:47 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-04 18:22 [Qemu-devel] [PATCH v9 00/20] Vhost and vhost-net support for userspace based backends Antonios Motakis
2014-03-04 18:22 ` [Qemu-devel] [PATCH v9 01/20] Convert -mem-path to QemuOpts and add share property Antonios Motakis
2014-03-04 18:22 ` [Qemu-devel] [PATCH v9 02/20] Add kvm_eventfds_enabled function Antonios Motakis
2014-03-04 18:22 ` [Qemu-devel] [PATCH v9 03/20] Add chardev API qemu_chr_fe_read_all Antonios Motakis
2014-03-04 18:22 ` [Qemu-devel] [PATCH v9 04/20] Add chardev API qemu_chr_fe_set_msgfds Antonios Motakis
2014-03-04 18:22 ` [Qemu-devel] [PATCH v9 05/20] Add chardev API qemu_chr_fe_get_msgfds Antonios Motakis
2014-03-04 18:22 ` [Qemu-devel] [PATCH v9 06/20] Add G_IO_HUP handler for socket chardev Antonios Motakis
2014-03-04 18:22 ` [Qemu-devel] [PATCH v9 07/20] vhost_net should call the poll callback only when it is set Antonios Motakis
2014-03-04 18:22 ` [Qemu-devel] [PATCH v9 08/20] Refactor virtio-net to use generic get_vhost_net Antonios Motakis
2014-03-04 18:22 ` [Qemu-devel] [PATCH v9 09/20] Add new virtio API virtio_queue_get_avail_idx Antonios Motakis
2014-03-04 18:22 ` [Qemu-devel] [PATCH v9 10/20] Gracefully handle ioctl failure in vhost_virtqueue_stop Antonios Motakis
2014-03-04 18:45   ` Michael S. Tsirkin
2014-03-05 13:38     ` Antonios Motakis
2014-03-05 13:47       ` Michael S. Tsirkin [this message]
2014-03-04 18:22 ` [Qemu-devel] [PATCH v9 11/20] vhost_net_init will use VhostNetOptions to get all its arguments Antonios Motakis
2014-03-04 18:22 ` [Qemu-devel] [PATCH v9 12/20] Add vhost_ops to vhost_dev struct and replace all relevant ioctls Antonios Motakis
2014-03-04 18:22 ` [Qemu-devel] [PATCH v9 13/20] Add mandatory_features to vhost_dev Antonios Motakis
2014-03-04 18:38   ` Michael S. Tsirkin
2014-03-05 13:40     ` Antonios Motakis
2014-03-04 18:22 ` [Qemu-devel] [PATCH v9 14/20] Add vhost-backend and VhostBackendType Antonios Motakis
2014-03-04 18:22 ` [Qemu-devel] [PATCH v9 15/20] Add vhost-user as a vhost backend Antonios Motakis
2014-03-04 18:22 ` [Qemu-devel] [PATCH v9 16/20] Add new vhost-user netdev backend Antonios Motakis
2014-03-04 18:23 ` [Qemu-devel] [PATCH v9 17/20] Add the vhost-user netdev backend to the command line Antonios Motakis
2014-03-04 18:23 ` [Qemu-devel] [PATCH v9 18/20] Add vhost-user protocol documentation Antonios Motakis
2014-03-04 18:23 ` [Qemu-devel] [PATCH v9 19/20] libqemustub: add stubs to be able to use qemu-char.c Antonios Motakis
2014-03-04 18:23 ` [Qemu-devel] [PATCH v9 20/20] Add qtest for vhost-user Antonios Motakis
2014-03-04 18:39   ` Andreas Färber
2014-03-05 13:39     ` Antonios Motakis
2014-03-04 18:29 ` [Qemu-devel] [PATCH v9 00/20] Vhost and vhost-net support for userspace based backends Paolo Bonzini
2014-03-04 18:33   ` Antonios Motakis
2014-03-04 18:38     ` Paolo Bonzini
2014-05-20 11:22   ` Nikolay Nikolaev
2014-05-20 12:51     ` Paolo Bonzini

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=20140305134731.GA25484@redhat.com \
    --to=mst@redhat.com \
    --cc=a.motakis@virtualopensystems.com \
    --cc=lukego@gmail.com \
    --cc=n.nikolaev@virtualopensystems.com \
    --cc=qemu-devel@nongnu.org \
    --cc=snabb-devel@googlegroups.com \
    --cc=tech@virtualopensystems.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).