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.
