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 > <[email protected]> wrote: > > > > On Tue, Oct 28, 2025 at 3:42 PM Michael S. Tsirkin <[email protected]> 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 <[email protected]> > > > > 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 > > > > > > <[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. > > > > > > > > > > > > > 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
