All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: yuri.benditovich@daynix.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH V2 RFT] vhost_net: don't set backend for the uninitialized virtqueue
Date: Mon, 1 Apr 2019 09:44:40 -0400	[thread overview]
Message-ID: <20190401093414-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <54169022-3b92-a49b-88b9-076e64a22e10@redhat.com>

On Wed, Mar 27, 2019 at 10:27:01AM +0800, Jason Wang wrote:
> 
> On 2019/3/26 下午8:49, Michael S. Tsirkin wrote:
> > On Tue, Mar 26, 2019 at 02:59:19PM +0800, Jason Wang wrote:
> > > On 2019/3/25 下午8:32, Michael S. Tsirkin wrote:
> > > > On Mon, Mar 25, 2019 at 11:56:13AM +0800, Jason Wang wrote:
> > > > > We used to set backend unconditionally, this won't work for some
> > > > > guests (e.g windows driver) who may not initialize all virtqueues. For
> > > > > kernel backend, this will fail since it may try to validate the rings
> > > > > during setting backend.
> > > > > 
> > > > > Fixing this by simply skipping the backend set when we find desc is
> > > > > not ready.
> > > > > 
> > > > > Signed-off-by: Jason Wang<jasowang@redhat.com>
> > > > > ---
> > > > >    hw/net/vhost_net.c | 15 +++++++++++++++
> > > > >    1 file changed, 15 insertions(+)
> > > > > 
> > > > > diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c
> > > > > index be3cc88370..04fd924d15 100644
> > > > > --- a/hw/net/vhost_net.c
> > > > > +++ b/hw/net/vhost_net.c
> > > > > @@ -221,6 +221,7 @@ static int vhost_net_start_one(struct vhost_net *net,
> > > > >                                   VirtIODevice *dev)
> > > > >    {
> > > > >        struct vhost_vring_file file = { };
> > > > > +    hwaddr a;
> > > > >        int r;
> > > > >        net->dev.nvqs = 2;
> > > > > @@ -244,6 +245,13 @@ static int vhost_net_start_one(struct vhost_net *net,
> > > > >            qemu_set_fd_handler(net->backend, NULL, NULL, NULL);
> > > > >            file.fd = net->backend;
> > > > >            for (file.index = 0; file.index < net->dev.nvqs; ++file.index) {
> > > > > +            a = virtio_queue_get_desc_addr(dev,
> > > > > +                                           net->dev.vq_index +
> > > > > +                                           file.index);
> > > > > +            if (a == 0) {
> > > > > +                /* Queue might not be ready for start */
> > > > > +                continue;
> > > > > +            }
> > > > >                r = vhost_net_set_backend(&net->dev, &file);
> > > > >                if (r < 0) {
> > > > >                    r = -errno;
> > > > > @@ -256,6 +264,13 @@ fail:
> > > > >        file.fd = -1;
> > > > >        if (net->nc->info->type == NET_CLIENT_DRIVER_TAP) {
> > > > >            while (file.index-- > 0) {
> > > > > +            a = virtio_queue_get_desc_addr(dev,
> > > > > +                                           net->dev.vq_index +
> > > > > +                                           file.index);
> > > > > +            if (a == 0) {
> > > > > +                /* Queue might not be ready for start */
> > > > > +                continue;
> > > > > +            }
> > > > >                int r = vhost_net_set_backend(&net->dev, &file);
> > > > >                assert(r >= 0);
> > > > >            }
> > > > I think we want an API that explicitly says "queue is enabled".
> > > > For 0.X it will return !!addr. For 1.X it will return enabled.
> > > For 1.x, desc.addr won't be set until queue_enabled is set through
> > > virtio_queue_set_vrings(). And it looks to me ccw did something similar of
> > > CMD_SET_VQ.
> > > 
> > > So we're ok actually?
> > > 
> > > Thanks
> > > 
> > OK maybe but why can't we use an explicit API?
> > 0.X can use addr != 0 trick since there's no queue_enabled.
> > 
> 
> If I understand correctly, you want something similar to what V1 did? A bus
> specific queue_enable() method.
> 
> Thanks

For now all I am asking for is simply:
	virtio_queue_is_enabled() {
		/* desc is only set when queue is enabled */
		return vdev->vq[n].vring.desc != 0;
}

and then we can look at moving the enabled flag into
struct VRing longer term.


-- 
MST

       reply	other threads:[~2019-04-01 13:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190325035613.18192-1-jasowang@redhat.com>
     [not found] ` <20190325074939-mutt-send-email-mst@kernel.org>
     [not found]   ` <92955c79-8389-85d5-cc1a-545c35aceb74@redhat.com>
     [not found]     ` <20190326084809-mutt-send-email-mst@kernel.org>
     [not found]       ` <54169022-3b92-a49b-88b9-076e64a22e10@redhat.com>
2019-04-01 13:44         ` Michael S. Tsirkin [this message]
2019-04-08  6:51           ` [Qemu-devel] [PATCH V2 RFT] vhost_net: don't set backend for the uninitialized virtqueue Jason Wang

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=20190401093414-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=yuri.benditovich@daynix.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 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.