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 <[email protected]> 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.

-- 
MST


Reply via email to