From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57429) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YstJg-0001UR-Ax for qemu-devel@nongnu.org; Thu, 14 May 2015 09:36:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YstJd-0000fw-2K for qemu-devel@nongnu.org; Thu, 14 May 2015 09:36:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35877) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YstJc-0000fF-Sm for qemu-devel@nongnu.org; Thu, 14 May 2015 09:36:44 -0400 Date: Thu, 14 May 2015 15:36:37 +0200 From: Andrew Jones Message-ID: <20150514133637.GE12812@localhost.localdomain> References: <1431516714-25816-1-git-send-email-drjones@redhat.com> <20150514103150.GA12812@localhost.localdomain> <20150514130318.GC12812@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [RFC/RFT PATCH v2 0/3] KVM: Introduce KVM_MEM_UNCACHED List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Ard Biesheuvel , Marc Zyngier , Catalin Marinas , Alexander Graf , QEMU Developers , Paolo Bonzini , Laszlo Ersek , "kvmarm@lists.cs.columbia.edu" , Christoffer Dall On Thu, May 14, 2015 at 02:11:59PM +0100, Peter Maydell wrote: > On 14 May 2015 at 14:03, Andrew Jones wrote: > > On Thu, May 14, 2015 at 11:37:46AM +0100, Peter Maydell wrote: > >> On 14 May 2015 at 11:31, Andrew Jones 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