From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3DCF5C43331 for ; Tue, 12 Nov 2019 17:15:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1349621D7F for ; Tue, 12 Nov 2019 17:15:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="BV3xxOHW" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727316AbfKLRPa (ORCPT ); Tue, 12 Nov 2019 12:15:30 -0500 Received: from mail-ot1-f68.google.com ([209.85.210.68]:41835 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726008AbfKLRP3 (ORCPT ); Tue, 12 Nov 2019 12:15:29 -0500 Received: by mail-ot1-f68.google.com with SMTP id 94so14968183oty.8 for ; Tue, 12 Nov 2019 09:15:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JVzIXHrO764GfG4Qiqm8/IBriT7RsdH75hTLmp9BmRA=; b=BV3xxOHWbIQpFI5CB7uozaEEkwDC3lyWKTSTyPa4TC3Rd1nV/7MnrtvXeaQ1Zn/abG nhzwgNg+HMP/zc7thH3+NozpyQbz1ePQ/ASz5y+YgICE0CRqSZzdHbEDliWn//CnYMRu vHRCY+Y8CVfx8lHiYzbdQMlPFcMr0aCT+stJMsIb3zLNuQGMY/pTwW26u1A1i3C9XOW+ nw+Nq64NnYGla6dF2P9v2y4kMFTef25LsJwSzbFUjnSsxuStNJXwc4PC154fjf3VfdPF 5LsksQleIaBa3iFOcbqYVbhweUIDtdGWopLOAv0G/rosJkOeTyOR/j9fGyVuxi7E4yrJ BsoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JVzIXHrO764GfG4Qiqm8/IBriT7RsdH75hTLmp9BmRA=; b=HwvZGc1uTMMmioa4SA0NHQyKz5UpsBRDFsKmJ+csJTAu5O2qkCM0XufxnFF9ysu3uI e+LBMN86mEd4kOQe/ftF7jhyyev5Ic4rx4cQfyCS6/0SCiM5SI6GPVT1sB84i05qLv4I /kv15pq3sihET9TBxf4PHpRj2C93a5RqR02gGiC4DmHRiobLHp6prWkB9/wnFeiaBFts 6Ik9AIdRFOhiuH5HYvOeBA4U53aKUHDrybj23R3Sus4ctv4Zev+Ys4GBSU6TgsTXdY+N pNJEygpqYgFGpQxah0o2j8vLOV5XKTvNYivY8w5DtmokUub+WkD9vHHO9p0zuBC8pktI 0I5w== X-Gm-Message-State: APjAAAVvjphMeHBNtDw8552yLKho4MmfveImANtWmSvDmvmYa0zsBzll AUzmFsmZX6CTWAPMVP01e8lqwFdTiFSTH5NquJs36g== X-Google-Smtp-Source: APXvYqxBWRXUbhgUeJAvflllA99xOkq97GoI6xicPLh5pWfFwhtbLObGxHb1Ub62atqTxWhI8Bsq8hQNoxBqMIRsSJw= X-Received: by 2002:a9d:5f11:: with SMTP id f17mr4555105oti.207.1573578928797; Tue, 12 Nov 2019 09:15:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dan Williams Date: Tue, 12 Nov 2019 09:15:18 -0800 Message-ID: Subject: Re: DAX filesystem support on ARMv8 To: Bharat Kumar Gogada Cc: "linux-nvdimm@lists.01.org" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "willy@infradead.org" , "viro@zeniv.linux.org.uk" , "jack@suse.cz" Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, Nov 11, 2019 at 6:12 PM Bharat Kumar Gogada wrote: > > Hi All, > > As per Documentation/filesystems/dax.txt > > The DAX code does not work correctly on architectures which have virtually > mapped caches such as ARM, MIPS and SPARC. > > Can anyone please shed light on dax filesystem issue w.r.t ARM architecture ? The concern is VIVT caches since the kernel will want to flush pmem addresses with different virtual addresses than what userspace is using. As far as I know, ARMv8 has VIPT caches, so should not have an issue. Willy initially wrote those restrictions, but I am assuming that the concern was managing the caches in the presence of virtual aliases.