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: Robert Elz <kre%munnari.OZ.AU@localhost>
Cc: 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: Mon, 30 Mar 2026 22:43:11 -0700

 > On Mar 30, 2026, at 9:41=E2=80=AFAM, Robert Elz <kre%munnari.OZ.AU@localhost> =
 wrote:
 >=20
 > So, I'm not sure that the general concept is quite as absurd as it =
 seems
 > at first glance - it might help locate all kinds of caching issues =
 such
 > as the one Taylor described.
 
 While what you say is true, it=E2=80=99s important to remember that one =
 of the design goals of VirtIO was to break through performance =
 bottlenecks associated with emulating actual hardware devices (which =
 includes all of the cache interaction).
 
 I=E2=80=99m not saying that this use if VirtIO couldn=E2=80=99t be =
 useful.. but it=E2=80=99s also worth considering that the issues in this =
 case may not lie with the bus_dma back-end but rather with the VirtIO =
 code in the kernel itself (based on my preliminary conversion with =
 Taylor about the problem).  It=E2=80=99s been demonstrated by years of =
 =E2=80=9Cworking at all=E2=80=9D that the m68k bus_dma back-end does in =
 fact work (the virt68k copy was lifted straight from mvme68k and is one =
 of my next targets for de-duplication).
 
 Do we really want to add cache management overhead to the VirtIO layer =
 for the benefit of a system emulator when VirtIO itself as a system was =
 designed to be inherently coherent?  One could argue that any system =
 emulator which includes VirtIO has to accept the =E2=80=9Ccaches are =
 fully coherent with main memory=E2=80=9D model that seems to be implied =
 by VirtIO=E2=80=99s nature.
 
 -- thorpej