Re: [RFC 1/2] virtio_net: timeout control virtqueue commands

[Eugenio Perez Martin <eperezma@redhat.com>]

On Fri, Mar 13, 2026 at 1:06 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Fri, Mar 13, 2026 at 12:32:18PM +0100, Eugenio Perez Martin wrote:
> > On Fri, Mar 13, 2026 at 12:31 PM Eugenio Perez Martin
> > <eperezma@redhat.com> wrote:
> > >
> > > On Sun, Nov 9, 2025 at 10:47 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > >
> > > > On Wed, Nov 05, 2025 at 10:02:48AM +0100, Eugenio Perez Martin wrote:
> > > > > On Tue, Oct 28, 2025 at 3:57 PM Eugenio Perez Martin
> > > > > <eperezma@redhat.com> wrote:
> > > > > >
> > > > > > On Tue, Oct 28, 2025 at 3:42 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > > > >
> > > > > > > On Tue, Oct 28, 2025 at 03:37:09PM +0100, Eugenio Perez Martin wrote:
> > > > > > > > On Tue, Oct 28, 2025 at 3:10 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Oct 22, 2025 at 02:55:18PM +0200, Eugenio Perez Martin wrote:
> > > > > > > > > > On Wed, Oct 22, 2025 at 1:43 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Oct 22, 2025 at 12:50:53PM +0200, Eugenio Perez Martin wrote:
> > > > > > > > > > > > Let me switch to MQ as I think it illustrates the point better.
> > > > > > > > > > > >
> > > > > > > > > > > > IIUC the workflow:
> > > > > > > > > > > > a) virtio-net sends MQ_VQ_PAIRS_SET 2 to the device
> > > > > > > > > > > > b) VDUSE CVQ sends ok to the virtio-net driver
> > > > > > > > > > > > c) VDUSE CVQ sends the command to the VDUSE device
> > > > > > > > > > > > d) Now the virtio-net driver sends virtio-net sends MQ_VQ_PAIRS_SET 1
> > > > > > > > > > > > e) VDUSE CVQ sends ok to the virtio-net driver
> > > > > > > > > > > >
> > > > > > > > > > > > The device didn't process the MQ_VQ_PAIRS_SET 1 command at this point,
> > > > > > > > > > > > so it potentially uses the second rx queue. But, by the standard:
> > > > > > > > > > > >
> > > > > > > > > > > > The device MUST NOT queue packets on receive queues greater than
> > > > > > > > > > > > virtqueue_pairs once it has placed the VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET
> > > > > > > > > > > > command in a used buffer.
> > > > > > > > > > > >
> > > > > > > > > > > > So the driver does not expect rx buffers on that queue at all. From
> > > > > > > > > > > > the driver's POV, the device is invalid, and it could mark it as
> > > > > > > > > > > > broken.
> > > > > > > > > > >
> > > > > > > > > > > ok intresting. Note that if userspace processes vqs it should process
> > > > > > > > > > > cvq too. I don't know what to do in this case yet, I'm going on
> > > > > > > > > > > vacation, let me ponder this a bit.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Sure.
> > > > > > > > >
> > > > > > > > > So let me ask you this, how are you going to handle device reset?
> > > > > > > > > Same issue, it seems to me.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Well my proposal is to mark it as broken so it needs to be reset
> > > > > > > > manually.
> > > > > > >
> > > > > > >
> > > > > > > Heh but guest assumes after reset device does not poke at guest
> > > > > > > memory, and will free up and reuse that memory.
> > > > > > > If userspace still pokes at it -> plus plus ungood.
> > > > > > >
> > > > > >
> > > > > > I don't get this part. Once the device is reset, the device should not
> > > > > > poke at guest memory (unless it is malicious or similar). Why would it
> > > > > > do it?
> > > > >
> > > > > Friendly ping.
> > > >
> > > >
> > > >
> > > > OK I thought about it a bunch. A lot of net drivers actually
> > > > just queue ethtool commands and finish them asynchronously.
> > > > Thinkably virtio could expose an API on whether it is safe to
> > > > wait for buffers to be used. virtio-net would then either
> > > > send commands directly or do the asynchronous thing.
> > > > Hmm?
> > > >
> > >
> > > I think it's the best solution too, yes. The series [1] implements for
> > > set_rx_mode. We can do it for all the CVQ commands and then whitelist
> > > them in VDUSE code. Am I missing something? Does anyone foresee any
> > > command that will not be possible to convert?
> > >
> >
> > Adding the [1] link...
> >
> > [1] https://lore.kernel.org/netdev/20260112181626.20117-1-viswanathiyyappan@gmail.com/
>
> what's the status of that one?
>

Still under review.

Aleksandr Loktionov <aleksandr.loktionov@intel.com> added the
Reviewed-by tag to most of patches but he spotted a sync issue in the
realtek 8139cp driver.

https://lore.kernel.org/lkml/IA3PR11MB8986856F0C1BC5A02F29B32EE540A@IA3PR11MB8986.namprd11.prod.outlook.com/