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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250924021444-mutt-send-email-mst@kernel.org>
Date: Wed, 24 Sep 2025 02:16:25 -0400
From: "Michael S. Tsirkin" <mst@...hat.com>
To: Daniel Jurgens <danielj@...dia.com>
Cc: netdev@...r.kernel.org, jasowang@...hat.com, alex.williamson@...hat.com,
	pabeni@...hat.com, virtualization@...ts.linux.dev, parav@...dia.com,
	shshitrit@...dia.com, yohadt@...dia.com, xuanzhuo@...ux.alibaba.com,
	eperezma@...hat.com, shameerali.kolothum.thodi@...wei.com,
	jgg@...pe.ca, kevin.tian@...el.com, kuba@...nel.org,
	andrew+netdev@...n.ch, edumazet@...gle.com,
	Yishai Hadas <yishaih@...dia.com>
Subject: Re: [PATCH net-next v3 01/11] virtio-pci: Expose generic device
 capability operations

On Tue, Sep 23, 2025 at 09:19:10AM -0500, Daniel Jurgens wrote:
> Currently querying and setting capabilities is restricted to a single
> capability and contained within the virtio PCI driver. However, each
> device type has generic and device specific capabilities, that may be
> queried and set. In subsequent patches virtio_net will query and set
> flow filter capabilities.
> 
> Move the admin related definitions to a new header file. It needs to be
> abstracted away from the PCI specifics to be used by upper layer
> drivers.
> 
> Signed-off-by: Daniel Jurgens <danielj@...dia.com>
> Reviewed-by: Parav Pandit <parav@...dia.com>
> Reviewed-by: Shahar Shitrit <shshitrit@...dia.com>
> Reviewed-by: Yishai Hadas <yishaih@...dia.com>


...


> +/**
> + * struct virtio_admin_ops - Operations for virtio admin functionality
> + *
> + * This structure contains function pointers for performing administrative
> + * operations on virtio devices. All data and caps pointers must be allocated
> + * on the heap by the caller.
> + */
> +struct virtio_admin_ops {
> +	/**
> +	 * @cap_id_list_query: Query the list of supported capability IDs
> +	 * @vdev: The virtio device to query
> +	 * @data: Pointer to result structure (must be heap allocated)
> +	 * Return: 0 on success, negative error code on failure
> +	 */
> +	int (*cap_id_list_query)(struct virtio_device *vdev,
> +				 struct virtio_admin_cmd_query_cap_id_result *data);
> +	/**
> +	 * @cap_get: Get capability data for a specific capability ID
> +	 * @vdev: The virtio device
> +	 * @id: Capability ID to retrieve
> +	 * @caps: Pointer to capability data structure (must be heap allocated)
> +	 * @cap_size: Size of the capability data structure
> +	 * Return: 0 on success, negative error code on failure
> +	 */
> +	int (*cap_get)(struct virtio_device *vdev,
> +		       u16 id,
> +		       void *caps,
> +		       size_t cap_size);
> +	/**
> +	 * @cap_set: Set capability data for a specific capability ID
> +	 * @vdev: The virtio device
> +	 * @id: Capability ID to set
> +	 * @caps: Pointer to capability data structure (must be heap allocated)
> +	 * @cap_size: Size of the capability data structure
> +	 * Return: 0 on success, negative error code on failure
> +	 */
> +	int (*cap_set)(struct virtio_device *vdev,
> +		       u16 id,
> +		       const void *caps,
> +		       size_t cap_size);
> +};
> +


I do not get why do we need this indirection. There is a single
implementation in the spec for now, and your patchset does not introduce
a new one.


-- 
MST


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ