On Thu, Mar 24, 2022 at 6:41 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote:
>
> On Thu, Mar 24, 2022 at 04:34:56PM +0800, Xuan Zhuo wrote:
> > On Tue, 22 Mar 2022 14:02:47 +0800, Jason Wang <jasowang@xxxxxxxxxx> wrote:
> > >
> > > 在 2022/3/14 下午5:34, Xuan Zhuo 写道:
> > > > Introduce virtqueue_resize() to implement the resize of vring.
> > > > Based on these, the driver can dynamically adjust the size of the vring.
> > > > For example: ethtool -G.
> > > >
> > > > virtqueue_resize() implements resize based on the vq reset function. In
> > > > case of failure to allocate a new vring, it will give up resize and use
> > > > the original vring.
> > > >
> > > > During this process, if the re-enable reset vq fails, the vq can no
> > > > longer be used. Although the probability of this situation is not high.
> > > >
> > > > The parameter recycle is used to recycle the buffer that is no longer
> > > > used.
> > > >
> > > > Signed-off-by: Xuan Zhuo <xuanzhuo@xxxxxxxxxxxxxxxxx>
> > > > ---
> > > > drivers/virtio/virtio_ring.c | 67 ++++++++++++++++++++++++++++++++++++
> > > > include/linux/virtio.h | 3 ++
> > > > 2 files changed, 70 insertions(+)
> > > >
> > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > > > index fb0abf9a2f57..b1dde086a8a4 100644
> > > > --- a/drivers/virtio/virtio_ring.c
> > > > +++ b/drivers/virtio/virtio_ring.c
> > > > @@ -2528,6 +2528,73 @@ struct virtqueue *vring_create_virtqueue(
> > > > }
> > > > EXPORT_SYMBOL_GPL(vring_create_virtqueue);
> > > >
> > > > +/**
> > > > + * virtqueue_resize - resize the vring of vq
> > > > + * @vq: the struct virtqueue we're talking about.
> > > > + * @num: new ring num
> > > > + * @recycle: callback for recycle the useless buffer
> > > > + *
> > > > + * When it is really necessary to create a new vring, it will set the current vq
> > > > + * into the reset state. Then call the passed cb to recycle the buffer that is
> > > > + * no longer used. Only after the new vring is successfully created, the old
> > > > + * vring will be released.
> > > > + *
> > > > + * Caller must ensure we don't call this with other virtqueue operations
> > > > + * at the same time (except where noted).
> > > > + *
> > > > + * Returns zero or a negative error.
> > > > + * -ENOMEM: create new vring fail. But vq can still work
> > > > + * -EBUSY: reset/re-enable vq fail. vq may cannot work
> > > > + * -ENOENT: not support resize
> > > > + * -E2BIG/-EINVAL: param num error
> > > > + */
> > > > +int virtqueue_resize(struct virtqueue *vq, u32 num,
> > > > + void (*recycle)(struct virtqueue *vq, void *buf))
> > > > +{
> > > > + struct virtio_device *vdev = vq->vdev;
> > > > + void *buf;
> > > > + int err;
> > > > +
> > > > + if (num > vq->num_max)
> > > > + return -E2BIG;
> > > > +
> > > > + if (!num)
> > > > + return -EINVAL;
> > > > +
> > > > + if (to_vvq(vq)->packed.vring.num == num)
> > > > + return 0;
> > >
> > >
> > > Any reason we need to check a packed specific attribute here?
> >
> > This is a mistake. Sorry for this.
> >
> > >
> > >
> > > > +
> > > > + if (!vq->vdev->config->reset_vq)
> > > > + return -ENOENT;
> > > > +
> > > > + if (!vq->vdev->config->enable_reset_vq)
> > > > + return -ENOENT;
> > > > +
> > > > + err = vq->vdev->config->reset_vq(vq);
> > > > + if (err) {
> > > > + if (err != -ENOENT)
> > > > + err = -EBUSY;
> > > > + return err;
> > > > + }
> > > > +
> > > > + while ((buf = virtqueue_detach_unused_buf(vq)) != NULL)
> > > > + recycle(vq, buf);
> > > > +
> > > > + if (virtio_has_feature(vdev, VIRTIO_F_RING_PACKED))
> > > > + err = virtqueue_resize_packed(vq, num);
> > > > + else
> > > > + err = virtqueue_resize_split(vq, num);
> > > > +
> > > > + if (err)
> > > > + err = -ENOMEM;
> > >
> > >
> > > So this assumes that the -ENOMEM is the only possible error value for
> > > virtqueue_resize_xxx(). Is this true? (E.g wrong size)
> >
> > Yes, I want the user to know at which step the error is returned.
> >
> > >
> > >
> > > > +
> > > > + if (vq->vdev->config->enable_reset_vq(vq))
> > > > + return -EBUSY;
> > > > +
> > > > + return err;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(virtqueue_resize);
> > > > +
> > > > /* Only available for split ring */
> > > > struct virtqueue *vring_new_virtqueue(unsigned int index,
> > > > unsigned int num,
> > > > diff --git a/include/linux/virtio.h b/include/linux/virtio.h
> > > > index d59adc4be068..c86ff02e0ca0 100644
> > > > --- a/include/linux/virtio.h
> > > > +++ b/include/linux/virtio.h
> > > > @@ -91,6 +91,9 @@ dma_addr_t virtqueue_get_desc_addr(struct virtqueue *vq);
> > > > dma_addr_t virtqueue_get_avail_addr(struct virtqueue *vq);
> > > > dma_addr_t virtqueue_get_used_addr(struct virtqueue *vq);
> > > >
> > > > +int virtqueue_resize(struct virtqueue *vq, u32 num,
> > > > + void (*recycle)(struct virtqueue *vq, void *buf));
> > >
> > >
> > > I wonder what's the advantages of coupling virtqueue_reset in
> > > virtqueue_resize().
> >
> > This is Michael's comment on the previous version
> >
> > >
> > > It looks to me it wold be more flexible to let the driver do:
> > >
> > > rest()
> > >
> > > detach()
> > >
> > > resize()
> > >
> > > enable_reset()
> > >
> > > One reason is that in the future we may want to add more functionality
> > > e.g switching PASID during virtqueue reset.
> >
> > Michael, from Jason Wang's plan, should we go back to the original 4 api model?
> >
> > Thanks.
>
>
> Jason, I feel a single api is preferable, because the need to do reset
> as part of resize is an implementation detail, I can easily
> imagine virtio spec being extended with a resize interface
> which does not require a queue reset.
>
> Makes sense to you?
Yes. I'm fine with the single API then.
Thanks
>
> >
> > >
> > > Thanks
> > >
> > >
> > > > +
> > > > /**
> > > > * virtio_device - representation of a device using virtio
> > > > * @index: unique position on the virtio bus
> > >
>
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
