On Wed, 2011-09-28 at 16:20 -0500, Scott Wood wrote: > Sure, if there might be stale stuff in the icache, the guest will need > to invalidate that. But when running on real hardware, an OS does not > need to flush it out of data cache after a DMA transaction[1]. So > technically we just want a flush_dcache_range() for DMA. > > It's moot unless we can distinguish DMA writes from breakpoint writes, > though. > > -Scott > > [1] Most OSes may do this anyway, to avoid needing to special case when > the dirtying is done entirely by DMA (or to avoid making assumptions > that could be broken by weird hardware), but that doesn't mean QEMU/KVM > should assume that -- maybe unless there's enough performance to be > gained by looking like the aforementioned "weird hardware" in certain > configurations. I see what you mean. A DMA would have had an implicit cache flush while qemu memcpy'ing to the guest won't. Hrm. I'm not sure any guest relies on that since architecturally, the HW is permitted to do cache intervention tricks, and rather than flush, transfer the data directly to the cache that originally contained the lines (cache injection). We do even support that on some embedded stuff. In any case, we should then make that depend on a flag, because it's certainly unnecessary on P5, P6 and P7 which have a snooping icache and can be costly. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
