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

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

> On Apr 2, 2026, at 5:00 AM, Tetsuya Isaki <isaki%pastel-flower.jp@localhost> wrote:
> 
> At Tue, 31 Mar 2026 06:46:34 -0700,
> Jason Thorpe wrote:
>> Please try:
>> 
>>    virt68k/virt68k/bus_dma.c:
>> 
>> $NetBSD: bus_dma.c,v 1.5 2026/03/31 13:45:00 thorpej Exp $
> 
> The spurious interrupt issue still occurs with this bus_dma.c,v 1.5
> patch.  When I rewrote it as below, the issue didn't seem to occur.
> 
> -       if (ops & BUS_DMASYNC_PREREAD) {
> +       if (ops & BUS_DMASYNC_POSTREAD) {

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.  The reason this would be problematic on 68040 is that the cache is configured to write-back mode and thus if any of the lines covering the relevant memory were to become dirty, the cache write-back would clobber the data just read into that memory as part of the DMA transaction.

Now, on real hardware there’s a catch: when DMA is taking place, the bus arbitration that the DMA controller engages in to acquire the bus for the DMA operation may, in fact, stall the cache fill, which could make this particular programming error harder to detect.  Does your implementation of 68030 cache emulation model the bus arbitration behavior?

> By the way I've tested it on -11 branch.  (because virt68k-current has
> another issue.  I'll report once this issue is resolved)

I’m assuming on emulated-68030 only?  In any case, thanks, looking forward to the report.

-- thorpej