[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3b3a8537-22f4-46c3-9142-78a00e65d43c@nvidia.com>
Date: Fri, 26 Sep 2025 10:08:32 -0500
From: Dan Jurgens <danielj@...dia.com>
To: "Michael S. Tsirkin" <mst@...hat.com>, Jason Wang <jasowang@...hat.com>
Cc: netdev@...r.kernel.org, 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 9/26/25 9:26 AM, Michael S. Tsirkin wrote:
> On Fri, Sep 26, 2025 at 12:55:11PM +0800, Jason Wang wrote:
>>>> Looking at this, it's nothing admin virtqueue specific, I wonder why
>>>> it is not part of virtio_config_ops.
>>>>
>>>> Thanks
>>>
>>> cap things are admin commands. But what I do not get is why they
>>> need to be callbacks.
>>>
>>> The only thing about admin commands that is pci specific is finding
>>> the admin vq.
>>
>> I think we had a discussion to decide to separate admin commands from
>> the admin vq.
>>
>> Thanks
>
> If what you are saying is that core should expose APIs to
> submit admin commands, not to access admin vq, I think I agree.
>
Quick overview of what I did, to not waste a v4 if you don't agree.
Added config_ops->admin_cmd_exec. virtio_pci_modern registers
virtio_pci_modern_admin_cmd_exec to it.
Moved the logic that had been in virtio_pci_modern for building the
commands and returning the data to a new file file virtio_admin_commands.c.
That file has the 5 functions needed for cap and object creation.
Powered by blists - more mailing lists