Re: kern/60144: virtio(4) cache coherence issue

["Jason Thorpe via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/60144; it has been noted by GNATS.

From: Jason Thorpe <thorpej%me.com@localhost>
To: Tetsuya Isaki <isaki%pastel-flower.jp@localhost>
Cc: Taylor Campbell <riastradh%netbsd.org@localhost>,
 gnats-bugs%netbsd.org@localhost,
 kern-bug-people%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/60144: virtio(4) cache coherence issue
Date: Fri, 10 Apr 2026 04:48:32 -0700

 > On Apr 9, 2026, at 9:58=E2=80=AFPM, Tetsuya Isaki =
 <isaki%pastel-flower.jp@localhost> wrote:
 >=20
 > At Thu, 2 Apr 2026 05:42:10 -0700,
 > Jason Thorpe wrote:
 >> If that=E2=80=99s the case, then I=E2=80=99d be concerned that =
 there=E2=80=99s some other
 >> issue in the virtio code that could cause a problem on 68040 as
 >> well, because what it indicates is that, after the cache was
 >> invalidated, something accessed the relevant memory (or memory
 >> adjacent enough to the relevant memory) that caused a cache line
 >> fill to take place, thus putting data that=E2=80=99s about to be =
 stale back
 >> into the cache.
 >=20
 > Thank you for your suggestion.
 > I found it.
 
 Good sleuthing!
 
 <snip>
 
 > vq->vq_used is shared region between the driver(CPU) and the =
 device(HW),
 > and is defined as:
 >=20
 >  struct vring_used {
 >        uint16_t flags;
 >        uint16_t idx;
 >        struct vring_used_elem ring[];
 > /* trailed by uint16_t avail_event when VIRTIO_F_RING_EVENT_IDX */
 >  } __packed;
 >=20
 > Reading vq->vq_used->flags here will also load the adjacent
 > vq->vq_used->idx into the cache (at least on the 68030 cache system).
 > This cached idx may still remain in the cache in the next interrupt
 > handler even though the virtio device has already updated idx in =
 memory.
 
 Ok, I would definitely argue that this is (a) either a virtio bug, or =
 (b) proof that virtio inherently assumes that the shared memory used by =
 the messaging system is coherent (also note that the ring entries are =
 tightly packed and no apparent effort is made in the spec to segregate =
 them into their own cache lines).  We=E2=80=99re basically lucky that =
 it=E2=80=99s a read filling the cache, because if it were a write by the =
 CPU, it would be possible to dirty an unrelated ring entry and clobber =
 it during a PREWRITE operation.
 
 Taylor, what=E2=80=99s your take on the situation?
 
 -- thorpej