From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: [PATCH v2 resend] ARM/arm64: KVM: test properly for a PTE's uncachedness Date: Tue, 10 Nov 2015 15:16:03 +0100 Message-ID: <20151110141603.GF12968@cbox> References: <1447164680-16330-1-git-send-email-ard.biesheuvel@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: marc.zyngier@arm.com, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org To: Ard Biesheuvel Return-path: Content-Disposition: inline In-Reply-To: <1447164680-16330-1-git-send-email-ard.biesheuvel@linaro.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu List-Id: kvm.vger.kernel.org On Tue, Nov 10, 2015 at 03:11:20PM +0100, Ard Biesheuvel wrote: > The open coded tests for checking whether a PTE maps a page as > uncached use a flawed '(pte_val(xxx) & CONST) != CONST' pattern, > which is not guaranteed to work since the type of a mapping is > not a set of mutually exclusive bits > > For HYP mappings, the type is an index into the MAIR table (i.e, the > index itself does not contain any information whatsoever about the > type of the mapping), and for stage-2 mappings it is a bit field where > normal memory and device types are defined as follows: > > #define MT_S2_NORMAL 0xf > #define MT_S2_DEVICE_nGnRE 0x1 > > I.e., masking *and* comparing with the latter matches on the former, > and we have been getting lucky merely because the S2 device mappings > also have the PTE_UXN bit set, or we would misidentify memory mappings > as device mappings. > > Since the unmap_range() code path (which contains one instance of the > flawed test) is used both for HYP mappings and stage-2 mappings, and > considering the difference between the two, it is non-trivial to fix > this by rewriting the tests in place, as it would involve passing > down the type of mapping through all the functions. > > However, since HYP mappings and stage-2 mappings both deal with host > physical addresses, we can simply check whether the mapping is backed > by memory that is managed by the host kernel, and only perform the > D-cache maintenance if this is the case. > > Signed-off-by: Ard Biesheuvel > Tested-by: Pavel Fedin > Reviewed-by: Christoffer Dall Thanks, applied. -Christoffer