On Tue, Dec 30, 2025 at 08:12:47AM -0500, Michael S. Tsirkin wrote:

On Sun, Dec 28, 2025 at 02:49:03PM -0800, Cong Wang wrote:

quoted

On Sun, Dec 28, 2025 at 02:31:36PM -0500, Michael S. Tsirkin wrote:

quoted

On Sat, Dec 27, 2025 at 05:54:51PM -0800, Cong Wang wrote:

quoted

From: Cong Wang <redacted>

The virtio-vsock driver triggers a DMA debug warning during probe:

[...]

quoted

quoted

This occurs because event_list[8] contains 8 struct virtio_vsock_event
entries, each only 4 bytes (__le32 id). When virtio_vsock_event_fill()
creates DMA mappings for all 8 events via virtqueue_add_inbuf(), these
32 bytes all fit within a single 64-byte cacheline.

The DMA debug subsystem warns about this because multiple DMA_FROM_DEVICE
mappings within the same cacheline can cause data corruption: if the CPU
writes to one event while the device is writing another event in the same
cacheline, the CPU cache writeback could overwrite device data.

But the CPU never writes into one of these, or did I miss anything?

The real issue is other data in the same cache line?

You are right, it is misleading.

The CPU never writes to the event buffers themselves, it only reads them
after the device writes. The problem is other struct fields in the same
cacheline.

I will update the commit message.

quoted

You want virtqueue_map_alloc_coherent/virtqueue_map_free_coherent
methinks.

Then you can use normal inbuf/outbut and not muck around with premapped.


I prefer keeping fancy premapped APIs for perf sensitive code,
let virtio manage DMA API otherwise.

Yes, I was not aware of these API's, they are indeed better than using
DMA API's directly.

Thanks!
Cong

BTW I sent an RFC fixing these bugs in all drivers. Review/testing would
be appreciated.

Thanks for taking care of it.

In case you need, it is 100% reproducible with CONFIG_DMA_API_DEBUG=y.

If you need my config, here it is:
https://github.com/congwang/kernelconfig/blob/master/kvm-debug-config

Regards,
Cong Wang