On 19.02.15 15:56, Ard Biesheuvel wrote: > On 19 February 2015 at 14:50, Alexander Graf <ag...@suse.de> wrote: >> >> >> On 19.02.15 11:54, Ard Biesheuvel wrote: >>> This is a 0th order approximation of how we could potentially force the >>> guest >>> to avoid uncached mappings, at least from the moment the MMU is on. (Before >>> that, all of memory is implicitly classified as Device-nGnRnE) >>> >>> The idea (patch #2) is to trap writes to MAIR_EL1, and replace uncached >>> mappings >>> with cached ones. This way, there is no need to mangle any guest page >>> tables. >> >> Would you mind to give a brief explanation on what this does? What >> happens to actually assigned devices that need to be mapped as uncached? >> What happens to DMA from such devices when the guest assumes that it's >> accessing RAM uncached and then triggers DMA? >> > > On ARM, stage 2 mappings that are more strict will supersede stage 1 > mappings, so the idea is to use cached mappings exclusively for stage > 1 so that the host is fully in control of the actual memory attributes > by setting the attributes at stage 2. This also makes sense because > the host will ultimately know better whether some range that the guest > thinks is a device is actually a device or just emulated (no stage 2 > mapping), backed by host memory (such as the NOR flash read case) or > backed by a passthrough device.
Ok, so that means if the guest maps RAM as uncached, it will actually end up as cached memory. Now if the guest triggers a DMA request to a passed through device to that RAM, it will conflict with the cache. I don't know whether it's a big deal, but it's the scenario that came up with the approach above before when I talked to people about it. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
