On Thu, May 14, 2015 at 02:11:59PM +0100, Peter Maydell wrote: > On 14 May 2015 at 14:03, Andrew Jones <drjones@xxxxxxxxxx> wrote: > > On Thu, May 14, 2015 at 11:37:46AM +0100, Peter Maydell wrote: > >> On 14 May 2015 at 11:31, Andrew Jones <drjones@xxxxxxxxxx> wrote: > >> > Forgot to (4): switch from setting userspace's mapping to > >> > device memory to normal, non-cacheable. Using device memory > >> > caused a problem that Alex Graf found, and Peter Maydell suggested > >> > using normal, non-cacheable instead. > >> > >> Did you check that non-cacheable is definitely the correct > >> kind of Normal memory attribute we want? (ie not write-through). > > > > I was concerned that write-through wouldn't be sufficient. If the > > guest writes to its non-cached memory, and QEMU needs to see what > > it wrote, then won't write-through fail to work? Unless we some > > how invalidate the cache first? > > Well, I meant more that the correct mapping for userspace is > the same as the guest, whatever that is, and so somebody needs > to look at what the guest actually does rather than merely > hoping NormalNC is OK. (For instance, do we need to provide > support for QEMU to map both NC and writethrough?) > Ah, we assume the guest is mapping it as device memory, and in this version of the series, I ensure that it is at least NC with the S2 attributes. I don't think we can look at what some guests do with some devices to come up with anything beyond (poor?) heuristics. I prefer that we force both the guest and QEMU to NC (or guest chooses Device and QEMU is forced to NC) to make sure we get it right. drew _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
