On 19 February 2015 at 15:27, Alexander Graf <agraf@xxxxxxx> wrote: > > > On 19.02.15 15:56, Ard Biesheuvel wrote: >> On 19 February 2015 at 14:50, Alexander Graf <agraf@xxxxxxx> 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. > Well, I am using write-through read+write allocate, which hopefully means that the actual RAM is kept in sync with the cache, but I must confess I am a bit out of my depth here with the fine print in the ARM ARM. -- 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
