qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Dima Stepanov <dimastep@yandex-team.ru>
To: Raphael Norwitz <raphael.s.norwitz@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Laurent Vivier <lvivier@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	qemu-block@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
	jasowang@redhat.com, QEMU <qemu-devel@nongnu.org>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Raphael Norwitz <raphael.norwitz@nutanix.com>,
	fengli@smartx.com, yc-core@yandex-team.ru,
	Paolo Bonzini <pbonzini@redhat.com>,
	Max Reitz <mreitz@redhat.com>
Subject: Re: [PATCH v2 2/7] vhost: check queue state in the vhost_dev_set_log routine
Date: Mon, 31 Aug 2020 11:37:40 +0300	[thread overview]
Message-ID: <20200831083740.GA6083@dimastep-nix> (raw)
In-Reply-To: <CAFubqFsnc3VjkYB-CqgeQ6Knwtvgb0Zyw-nOHD1CugLzTBe9Ew@mail.gmail.com>

On Thu, Aug 27, 2020 at 09:46:03PM -0400, Raphael Norwitz wrote:
> On Mon, Aug 24, 2020 at 4:41 AM Dima Stepanov <dimastep@yandex-team.ru> wrote:
> >
> > If the vhost-user-blk daemon provides only one virtqueue, but device was
> > added with several queues, then QEMU will send more VHOST-USER command
> > than expected by daemon side. The vhost_virtqueue_start() routine
> > handles such case by checking the return value from the
> > virtio_queue_get_desc_addr() function call. Add the same check to the
> > vhost_dev_set_log() routine.
> >
> > Signed-off-by: Dima Stepanov <dimastep@yandex-team.ru>
> > ---
> >  hw/virtio/vhost.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
> > index ffef7ab..a33ffd4 100644
> > --- a/hw/virtio/vhost.c
> > +++ b/hw/virtio/vhost.c
> > @@ -825,12 +825,24 @@ static int vhost_dev_set_features(struct vhost_dev *dev,
> >  static int vhost_dev_set_log(struct vhost_dev *dev, bool enable_log)
> >  {
> >      int r, i, idx;
> > +    hwaddr addr;
> > +
> >      r = vhost_dev_set_features(dev, enable_log);
> >      if (r < 0) {
> >          goto err_features;
> >      }
> >      for (i = 0; i < dev->nvqs; ++i) {
> >          idx = dev->vhost_ops->vhost_get_vq_index(dev, dev->vq_index + i);
> > +        addr = virtio_queue_get_desc_addr(dev->vdev, idx);
> > +        if (!addr) {
> > +            /*
> > +             * The queue might not be ready for start. If this
> > +             * is the case there is no reason to continue the process.
> > +             * The similar logic is used by the vhost_virtqueue_start()
> > +             * routine.
> > +             */
> 
> Shouldn’t we goto err_vq here to reset the logging state of any vqs
> which have already been set?
As i understand it, no we shouldn't reset the state of other queues. In
general it is pretty valid case. Let's assume that the backend
vhost-user device supports only two queues. But for instance, the QEMU
command line is using value 4 to define number of virtqueues of such
device. In this case only 2 queues will be initializaed.

I've tried to reflect it in the comment section, that the
vhost_virtqueue_start() routine has been alread made the same:
  "if a queue isn't ready for start, just return 0 without any error"
So i made the same here.

I've found this issue, while testing migration with the default
vhost-user-blk daemon. It fails with assert or sigsegv (don't remember),
because it receives NULL for the queues it doesn't have. In general
the daemon should not fall, because of unexpected VHOST_USER
communication, but also there is no reason for QEMU to send additional
packets.

> 
> > +            break;
> > +        }
> >          r = vhost_virtqueue_set_addr(dev, dev->vqs + i, idx,
> >                                       enable_log);
> >          if (r < 0) {
> > --
> > 2.7.4
> >
> >


  reply	other threads:[~2020-08-31  8:43 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-24  8:39 [PATCH v2 0/7] vhost-user-blk: fix the migration issue and enhance qtests Dima Stepanov
2020-08-24  8:39 ` [PATCH v2 1/7] vhost: recheck dev state in the vhost_migration_log routine Dima Stepanov
2020-08-28  1:44   ` Raphael Norwitz
2020-08-31  8:24     ` Dima Stepanov
2020-08-24  8:39 ` [PATCH v2 2/7] vhost: check queue state in the vhost_dev_set_log routine Dima Stepanov
2020-08-28  1:46   ` Raphael Norwitz
2020-08-31  8:37     ` Dima Stepanov [this message]
2020-09-01  3:22       ` Raphael Norwitz
2020-09-01  8:36         ` Dima Stepanov
2020-08-24  8:39 ` [PATCH v2 3/7] tests/qtest/vhost-user-test: prepare the tests for adding new dev class Dima Stepanov
2020-08-24  8:39 ` [PATCH v2 4/7] tests/qtest/libqos/virtio-blk: add support for vhost-user-blk Dima Stepanov
2020-08-24  8:39 ` [PATCH v2 5/7] tests/qtest/vhost-user-test: add support for the vhost-user-blk device Dima Stepanov
2020-08-24  8:39 ` [PATCH v2 6/7] tests/qtest/vhost-user-test: add migrate_reconnect test Dima Stepanov
2020-08-24  8:39 ` [PATCH v2 7/7] tests/qtest/vhost-user-test: enable the reconnect tests Dima Stepanov
2020-08-24 13:46 ` [PATCH v2 0/7] vhost-user-blk: fix the migration issue and enhance qtests no-reply

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=20200831083740.GA6083@dimastep-nix \
    --to=dimastep@yandex-team.ru \
    --cc=dgilbert@redhat.com \
    --cc=fengli@smartx.com \
    --cc=jasowang@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=raphael.norwitz@nutanix.com \
    --cc=raphael.s.norwitz@gmail.com \
    --cc=thuth@redhat.com \
    --cc=yc-core@yandex-team.ru \
    /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).