linux-kernel - Re: [PATCH v4 09/14] virtio: queue_reset: struct virtio_config_ops add callbacks for queue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 11 Feb 2022 14:49:03 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
        linux-kernel@...r.kernel.org
Cc:     "Michael S. Tsirkin" <mst@...hat.com>,
        virtualization@...ts.linux-foundation.org
Subject: Re: [PATCH v4 09/14] virtio: queue_reset: struct virtio_config_ops
 add callbacks for queue_reset


在 2022/2/9 下午8:28, Xuan Zhuo 写道:
> Performing reset on a queue is divided into four steps:
>
> 1. reset_vq: reset one vq
> 2. recycle the buffer from vq by virtqueue_detach_unused_buf()
> 3. release the ring of the vq by vring_release_virtqueue()
> 4. enable_reset_vq: re-enable the reset queue
>
> So add two callbacks reset_vq, enable_reset_vq to struct
> virtio_config_ops.
>
> Signed-off-by: Xuan Zhuo <xuanzhuo@...ux.alibaba.com>
> ---
>   include/linux/virtio_config.h | 13 +++++++++++++
>   1 file changed, 13 insertions(+)
>
> diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
> index 4d107ad31149..0d01a64f2576 100644
> --- a/include/linux/virtio_config.h
> +++ b/include/linux/virtio_config.h
> @@ -74,6 +74,17 @@ struct virtio_shm_region {
>    * @set_vq_affinity: set the affinity for a virtqueue (optional).
>    * @get_vq_affinity: get the affinity for a virtqueue (optional).
>    * @get_shm_region: get a shared memory region based on the index.
> + * @reset_vq: reset a queue individually


This needs to be marked as optional I think.


> + *	vq: the virtqueue
> + *	Returns 0 on success or error status


It looks to me the caller should also guarantee that the vring is not 
accsed by any functions e.g NAPI.


> + *	After successfully calling this, be sure to call
> + *	virtqueue_detach_unused_buf() to recycle the buffer in the ring, and
> + *	then call vring_release_virtqueue() to release the vq ring.
> + * @enable_reset_vq: enable a reset queue
> + *	vq: the virtqueue
> + *	ring_num: specify ring num for the vq to be re-enabled. 0 means use the
> + *	          default value. MUST be a power of 2.


Note that we don't have power of 2 requirement for packed virtqueue.

And I wonder if it's cleaner to have a find_vq() ops instead to dealing 
with the re-allocation and possible size change, or have a dedicated 
helper to set vring size so driver can do.

reset_vq()

virtqueue_set_vring_size()

enable_reset_vq()


> + *	Returns 0 on success or error status
>    */
>   typedef void vq_callback_t(struct virtqueue *);
>   struct virtio_config_ops {
> @@ -100,6 +111,8 @@ struct virtio_config_ops {
>   			int index);
>   	bool (*get_shm_region)(struct virtio_device *vdev,
>   			       struct virtio_shm_region *region, u8 id);
> +	int (*reset_vq)(struct virtqueue *vq);
> +	int (*enable_reset_vq)(struct virtqueue *vq, u16 ring_num);


Note that the current implement is best-effort, so it's not guarantee 
that we can have a vring with ring_num, we may get less under memory 
pressure or even fail. We probably need to have a pamater to mandate the 
ring_num otherwise user may surprise to see a decreased size of the ring 
when a increasing is actually requested.

Thanks


>   };
>   
>   /* If driver didn't advertise the feature, it will never appear. */