Re: [Qemu-devel] [RFC/RFT PATCH v2 0/3] KVM: Introduce KVM_MEM_UNCACHED

[Christoffer Dall]

On Thu, May 14, 2015 at 03:36:37PM +0200, Andrew Jones wrote:
> On Thu, May 14, 2015 at 02:11:59PM +0100, Peter Maydell wrote:
> > On 14 May 2015 at 14:03, Andrew Jones <address@hidden> wrote:
> > > On Thu, May 14, 2015 at 11:37:46AM +0100, Peter Maydell wrote:
> > >> On 14 May 2015 at 11:31, Andrew Jones <address@hidden> 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.
> 
But picking up on Peter's feedback I think it would be good if the
series clearly states something like:

1) We assume that the guest may use device type memory for the accesses
2) we cannot use device memory for the userspace mapping because
userspace may be doing unaligned accesses to it 3) normal non-cacheable
bridges these worlds becauase of x, y, and z.

I assume x, y, and z would include a fairly involved discussion of the
interesting aspects of how you can configure memory accesses on ARM ...
:)

-Christoffer