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

["Michael S. Tsirkin" <mst@redhat.com>]

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?


-- 
MST