netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Dan Jurgens <danielj@nvidia.com>
Cc: netdev@vger.kernel.org, jasowang@redhat.com, pabeni@redhat.com,
	virtualization@lists.linux.dev, parav@nvidia.com,
	shshitrit@nvidia.com, yohadt@nvidia.com,
	xuanzhuo@linux.alibaba.com, eperezma@redhat.com, jgg@ziepe.ca,
	kevin.tian@intel.com, kuba@kernel.org, andrew+netdev@lunn.ch,
	edumazet@google.com
Subject: Re: [PATCH net-next v12 03/12] virtio: Expose generic device capability operations
Date: Mon, 24 Nov 2025 17:27:53 -0500	[thread overview]
Message-ID: <20251124172646-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <29fa4996-38e3-4146-81d3-f8b188e047e9@nvidia.com>

On Mon, Nov 24, 2025 at 04:24:37PM -0600, Dan Jurgens wrote:
> On 11/24/25 2:30 PM, Michael S. Tsirkin wrote:
> > On Wed, Nov 19, 2025 at 01:15:14PM -0600, 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.
> >>
> >> This changes the size of virtio_admin_cmd_query_cap_id_result. It's safe
> >> to do because this data is written by DMA, so a newer controller can't
> >> overrun the size on an older kernel.
> >>
> >> Signed-off-by: Daniel Jurgens <danielj@nvidia.com>
> >> Reviewed-by: Parav Pandit <parav@nvidia.com>
> >> Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> >>
> >> ---
> >> v4: Moved this logic from virtio_pci_modern to new file
> >>     virtio_admin_commands.
> >>
> >> v12:
> >>   - Removed uapi virtio_pci include in virtio_admin.h. MST
> >>   - Added virtio_pci uapi include to virtio_admin_commands.c
> >>   - Put () around cap in macro. MST
> >>   - Removed nonsense comment above VIRTIO_ADMIN_MAX_CAP. MST
> >>   - +1 VIRTIO_ADMIN_MAX_CAP when calculating array size. MST
> >>   - Updated commit message
> >> ---
> >>  drivers/virtio/Makefile                |  2 +-
> >>  drivers/virtio/virtio_admin_commands.c | 91 ++++++++++++++++++++++++++
> >>  include/linux/virtio_admin.h           | 80 ++++++++++++++++++++++
> >>  include/uapi/linux/virtio_pci.h        |  6 +-
> >>  4 files changed, 176 insertions(+), 3 deletions(-)
> >>  create mode 100644 drivers/virtio/virtio_admin_commands.c
> >>  create mode 100644 include/linux/virtio_admin.h
> >>
> >> diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
> >> index eefcfe90d6b8..2b4a204dde33 100644
> >> --- a/drivers/virtio/Makefile
> >> +++ b/drivers/virtio/Makefile
> >> @@ -1,5 +1,5 @@
> >>  # SPDX-License-Identifier: GPL-2.0
> >> -obj-$(CONFIG_VIRTIO) += virtio.o virtio_ring.o
> >> +obj-$(CONFIG_VIRTIO) += virtio.o virtio_ring.o virtio_admin_commands.o
> >>  obj-$(CONFIG_VIRTIO_ANCHOR) += virtio_anchor.o
> >>  obj-$(CONFIG_VIRTIO_PCI_LIB) += virtio_pci_modern_dev.o
> >>  obj-$(CONFIG_VIRTIO_PCI_LIB_LEGACY) += virtio_pci_legacy_dev.o
> >> diff --git a/drivers/virtio/virtio_admin_commands.c b/drivers/virtio/virtio_admin_commands.c
> >> new file mode 100644
> >> index 000000000000..a2254e71e8dc
> >> --- /dev/null
> >> +++ b/drivers/virtio/virtio_admin_commands.c
> >> @@ -0,0 +1,91 @@
> >> +// SPDX-License-Identifier: GPL-2.0-only
> >> +
> >> +#include <linux/virtio.h>
> >> +#include <linux/virtio_config.h>
> >> +#include <linux/virtio_admin.h>
> >> +#include <uapi/linux/virtio_pci.h>
> >> +
> >> +int virtio_admin_cap_id_list_query(struct virtio_device *vdev,
> >> +				   struct virtio_admin_cmd_query_cap_id_result *data)
> >> +{
> >> +	struct virtio_admin_cmd cmd = {};
> >> +	struct scatterlist result_sg;
> >> +
> >> +	if (!vdev->config->admin_cmd_exec)
> >> +		return -EOPNOTSUPP;
> >> +
> >> +	sg_init_one(&result_sg, data, sizeof(*data));
> >> +	cmd.opcode = cpu_to_le16(VIRTIO_ADMIN_CMD_CAP_ID_LIST_QUERY);
> >> +	cmd.group_type = cpu_to_le16(VIRTIO_ADMIN_GROUP_TYPE_SELF);
> >> +	cmd.result_sg = &result_sg;
> >> +
> >> +	return vdev->config->admin_cmd_exec(vdev, &cmd);
> >> +}
> >> +EXPORT_SYMBOL_GPL(virtio_admin_cap_id_list_query);
> >> +
> >> +int virtio_admin_cap_get(struct virtio_device *vdev,
> >> +			 u16 id,
> >> +			 void *caps,
> >> +			 size_t cap_size)
> > 
> > 
> > I still don't get why cap_size needs to be as large as size_t.
> > 
> > if you don't care what's it size is, just say "unsigned".
> > or u8 as a hint to users it's a small value.
> 
> The size is small for net flow filters, but this is supposed to be a
> generic interface for future uses as well. Why limit it?

because your implementation
makes assumptions - if you want it to be truly generic then you need to handle
weird corner cases such as integer overflow when you add these things.


> 
> > 
> >> +{
> >> +	struct virtio_admin_cmd_cap_get_data *data;
> >> +	struct virtio_admin_cmd cmd = {};
> >> +	struct scatterlist result_sg;
> >> +	struct scatterlist data_sg;
> >> +	int err;
> >> +
> >> +	if (!vdev->config->admin_cmd_exec)
> >> +		return -EOPNOTSUPP;
> >> +
> >> +	data = kzalloc(sizeof(*data), GFP_KERNEL);
> > 
> > uses kzalloc without including linux/slab.h
> > 
> > 
> > 
> >> +	if (!data)
> >> +		return -ENOMEM;
> >> +


  reply	other threads:[~2025-11-24 22:28 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-19 19:15 [PATCH net-next v12 00/12] virtio_net: Add ethtool flow rules support Daniel Jurgens
2025-11-19 19:15 ` [PATCH net-next v12 01/12] virtio_pci: Remove supported_cap size build assert Daniel Jurgens
2025-11-19 19:15 ` [PATCH net-next v12 02/12] virtio: Add config_op for admin commands Daniel Jurgens
2025-11-19 19:15 ` [PATCH net-next v12 03/12] virtio: Expose generic device capability operations Daniel Jurgens
2025-11-24 20:30   ` Michael S. Tsirkin
2025-11-24 22:24     ` Dan Jurgens
2025-11-24 22:27       ` Michael S. Tsirkin [this message]
2025-11-19 19:15 ` [PATCH net-next v12 04/12] virtio: Expose object create and destroy API Daniel Jurgens
2025-11-19 19:15 ` [PATCH net-next v12 05/12] virtio_net: Query and set flow filter caps Daniel Jurgens
2025-11-20  1:51   ` Jakub Kicinski
2025-11-20 15:39     ` Dan Jurgens
2025-11-24 21:01   ` Michael S. Tsirkin
2025-11-25  0:05     ` Dan Jurgens
2025-11-24 22:54   ` Michael S. Tsirkin
2025-11-26  6:11     ` Dan Jurgens
2025-11-19 19:15 ` [PATCH net-next v12 06/12] virtio_net: Create a FF group for ethtool steering Daniel Jurgens
2025-11-19 19:15 ` [PATCH net-next v12 07/12] virtio_net: Implement layer 2 ethtool flow rules Daniel Jurgens
2025-11-24 21:05   ` Michael S. Tsirkin
2025-11-26 16:25     ` Dan Jurgens
2025-11-26 18:00       ` Michael S. Tsirkin
2025-11-25 14:25   ` Michael S. Tsirkin
2025-11-25 15:39     ` Dan Jurgens
2025-11-19 19:15 ` [PATCH net-next v12 08/12] virtio_net: Use existing classifier if possible Daniel Jurgens
2025-11-24 22:04   ` Michael S. Tsirkin
2025-11-24 22:31     ` Dan Jurgens
2025-11-24 22:38       ` Michael S. Tsirkin
2025-11-19 19:15 ` [PATCH net-next v12 09/12] virtio_net: Implement IPv4 ethtool flow rules Daniel Jurgens
2025-11-24 21:51   ` Michael S. Tsirkin
2025-11-24 22:41     ` Dan Jurgens
2025-11-26  5:48     ` Dan Jurgens
2025-11-19 19:15 ` [PATCH net-next v12 10/12] virtio_net: Add support for IPv6 ethtool steering Daniel Jurgens
2025-11-24 21:59   ` Michael S. Tsirkin
2025-11-24 23:04     ` Dan Jurgens
2025-11-24 23:12       ` Michael S. Tsirkin
2025-11-25  0:10         ` Dan Jurgens
2025-11-19 19:15 ` [PATCH net-next v12 11/12] virtio_net: Add support for TCP and UDP ethtool rules Daniel Jurgens
2025-11-24 22:02   ` Michael S. Tsirkin
2025-11-24 22:47     ` Dan Jurgens
2025-11-19 19:15 ` [PATCH net-next v12 12/12] virtio_net: Add get ethtool flow rules ops Daniel Jurgens
2025-11-19 20:22 ` [PATCH net-next v12 00/12] virtio_net: Add ethtool flow rules support Michael S. Tsirkin

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=20251124172646-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=danielj@nvidia.com \
    --cc=edumazet@google.com \
    --cc=eperezma@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=jgg@ziepe.ca \
    --cc=kevin.tian@intel.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=parav@nvidia.com \
    --cc=shshitrit@nvidia.com \
    --cc=virtualization@lists.linux.dev \
    --cc=xuanzhuo@linux.alibaba.com \
    --cc=yohadt@nvidia.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 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).