On Fri, Jan 05, 2024 at 05:12:37PM +0800, Yan Zhao wrote: > This series allow user space to notify KVM of noncoherent DMA status so as > to let KVM honor guest memory types in specified memory slot ranges. > > Motivation > === > A virtio GPU device may want to configure GPU hardware to work in > noncoherent mode, i.e. some of its DMAs do not snoop CPU caches. Does this mean some DMA reads do not snoop the caches or does it include DMA writes not synchronizing the caches too? > This is generally for performance consideration. > In certain platform, GFX performance can improve 20+% with DMAs going to > noncoherent path. > > This noncoherent DMA mode works in below sequence: > 1. Host backend driver programs hardware not to snoop memory of target > DMA buffer. > 2. Host backend driver indicates guest frontend driver to program guest PAT > to WC for target DMA buffer. > 3. Guest frontend driver writes to the DMA buffer without clflush stuffs. > 4. Hardware does noncoherent DMA to the target buffer. > > In this noncoherent DMA mode, both guest and hardware regard a DMA buffer > as not cached. So, if KVM forces the effective memory type of this DMA > buffer to be WB, hardware DMA may read incorrect data and cause misc > failures. I don't know all the details, but a big concern would be that the caches remain fully coherent with the underlying memory at any point where kvm decides to revoke the page from the VM. If you allow an incoherence of cache != physical then it opens a security attack where the observed content of memory can change when it should not. ARM64 has issues like this and due to that ARM has to have explict, expensive, cache flushing at certain points. Jason
