Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <CAFULd4b=5-=WfF9OPCX+H9VDnsgbN7OBFj-XP=MZ0QqF5WpvQA@mail.gmail.com>
 <8736j7gsza.fsf@linux.intel.com> <alpine.DEB.2.21.1907152033020.1767@nanos.tec.linutronix.de>
 <CAFULd4bcB8tsgZuxZJm_ksp5zyDQXjO=v_Ov622Bmhx=fr7KuA@mail.gmail.com>
 <alpine.DEB.2.21.1907152129350.1767@nanos.tec.linutronix.de> <20190715193836.GF32439@tassilo.jf.intel.com>
In-Reply-To: <20190715193836.GF32439@tassilo.jf.intel.com>
From:   Andy Lutomirski <luto@kernel.org>
Date:   Mon, 15 Jul 2019 15:12:15 -0700
Message-ID: <CALCETrVonxn6tDkxZnbetM9W4Uxxm7-M-tv1e7YsieX3U5OBKA@mail.gmail.com>
Subject: Re: [RFC PATCH, x86]: Disable CPA cache flush for selfsnoop targets
To:     Andi Kleen <ak@linux.intel.com>,
        Dave Hansen <dave.hansen@intel.com>,
        Peter Zijlstra <peterz@infradead.org>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Uros Bizjak <ubizjak@gmail.com>,
        LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
        Andrew Lutomirski <luto@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Jul 15, 2019 at 12:38 PM Andi Kleen <ak@linux.intel.com> wrote:
>
> >
> > That does not answer the question whether it's worthwhile to do that.
>
> It's likely worthwhile for (Intel integrated) graphics.
>
> There was also a recent issue with 3dxp/dax, which uses ioremap in some
> cases.
>


FWIW, I applied this simpler patch:

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 6a9a77a403c9..a933f99b176a 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1729,6 +1729,7 @@ static int change_page_attr_set_clr(unsigned
long *addr, int numpages,
         * attributes:
         */
        cache = !!pgprot2cachemode(mask_set);
+       WARN_ON(cache);

        /*
         * On error; flush everything to be sure.

and booted a VM, including loading a module.  The warning did not
fire.  For the most part, we use PAT for things like ioremap_wc(), but
there's no flush, since there's no preexisting mapping at all.

I haven't tested on a real kernel with i915.  Does i915 really hit
this code path?  Does it happen more than once or twice at boot?

The only case I can think of where this would really matter is DAX, if
anyone uses WT for DAX.