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

[Jason Thorpe <thorpej%me.com@localhost>]

> On Apr 9, 2026, at 9:58 PM, Tetsuya Isaki <isaki%pastel-flower.jp@localhost> wrote:
> 
> At Thu, 2 Apr 2026 05:42:10 -0700,
> Jason Thorpe wrote:
>> If that’s the case, then I’d be concerned that there’s 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’s about to be stale back
>> into the cache.
> 
> 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:
> 
>  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;
> 
> 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’re basically lucky that it’s 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’s your take on the situation?

-- thorpej