Re: [virtio-dev] May a device use buffers after putting them into the used ring?

[Stefan Hajnoczi <stefanha@redhat.com>]

On Fri, Feb 07, 2020 at 06:42:52PM +0100, Benedikt Radtke wrote:
> I am using qemu-system-arm with "-device virtio-net-device" to emulate a nic
> (mmio, legacy). I have noticed that a receive queue uses the same buffer
> multiple times, although it has been added to the used ring (and not been
> added to the available ring again). Is it allowed to do that?

No, that should not happen.  Once the device places a buffer in the used
ring it will not touch it again.

> This is the first buffer (index 0) in the descriptor table:
> (gdb) x/16x 0x46008000
> 0x46008000:     0x00000000      0x00000000      0xffff0000 0xffffffff
> 0x46008010:     0x000a5552      0x06080202      0x00080100 0x01000406
> 0x46008020:     0x000a5552      0x000a0202      0x00000202 0x00000000
> 0x46008030:     0x0f02000a      0x00000000      0x00000000 0x00000000
> As you can see it contains a legacy virtio_net_hdr and an ethernet frame
> with an arp packet.
> 
> After receiving two such arp packets the used ring looks like this:
> (gdb) x/8x 0x46005000
> 0x46005000:     0x00020001      0x00000000      0x00000034 0x00000000
> 0x46005010:     0x00000034      0x00000000      0x00000000 0x00000000

I didn't look at these hex dumps.  I don't have time to try to match
them up to the specification.  If you'd like help debugging the rings,
please annotate the hex dumps and describe what happens at each step.

> The used index is 2, and both entries use the first buffer in the descriptor
> table (0). The virtio 1.1 spec says in section 2.6.8 ("The Virtqueue Used
> Ring"): "The used ring is where the device returns buffers once it is done
> with them". I'd expect that any buffer that appears in the used ring will
> not be touched by the device (unless the driver puts it into an available
> ring again).
> 
> Is my interpretation of the phrasing wrong, or is the device misbehaving?

QEMU's virtio-net and virtio-mmio implementation isn't known to have
this bug.  It would have probably been noticed a long time ago.
Therefore it's likely that the bug is in new code that you're testing
(i.e. guest driver or device emulation).

Stefan

Attachment: signature.asc
Description: PGP signature