Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
To:     Borislav Petkov <bp@alien8.de>, Juergen Gross <jgross@suse.com>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
        "H. Peter Anvin" <hpa@zytor.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        David Hildenbrand <david@redhat.com>,
        Yu Zhao <yuzhao@google.com>, linux-kernel@vger.kernel.org,
        Marek =?ISO-8859-1?Q?Marczykowski=2DG=F3recki?= 
        <marmarek@invisiblethingslab.com>,
        Andi Shyti <andi.shyti@linux.intel.com>,
        intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [RESUBMIT][PATCH] x86/mm: Fix PAT bit missing from page protection modify
 mask
Date:   Mon, 05 Jun 2023 17:51:31 +0200
Message-ID: <2227080.iZASKD2KPV@jkrzyszt-mobl2.ger.corp.intel.com>
Organization: Intel Technology Poland sp. z o.o. - ul. Slowackiego 173,
 80-298 Gdansk - KRS 101882 - NIP 957-07-52-316
In-Reply-To: <5083c051-dfcf-ae23-195f-4c92bb875009@suse.com>
References: <20230519183634.190364-1-janusz.krzysztofik@linux.intel.com>
 <bd70e7b8-1971-6982-979a-ce1eb4c93465@suse.com>
 <5083c051-dfcf-ae23-195f-4c92bb875009@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

(fixed misspelled Cc: email address of intel-gfx list)

On Friday, 2 June 2023 16:53:30 CEST Juergen Gross wrote:
> On 02.06.23 16:48, Juergen Gross wrote:
> > On 02.06.23 16:43, Borislav Petkov wrote:
> >> On Thu, Jun 01, 2023 at 10:47:39AM +0200, Juergen Gross wrote:
> >>> As described in the commit message, this only works on bare metal due to 
the
> >>> PAT bit not being needed for WC mappings.
> >>>
> >>> Making this patch Xen specific would try to cure the symptoms without 
fixing
> >>> the underlying problem: _PAGE_PAT should be regarded the same way as the 
bits
> >>> for caching mode (_PAGE_CHG_MASK).
> >>
> >> So why isn't _PAGE_PAT part of _PAGE_CHG_MASK?
> > 
> > This would result in problems for large pages: _PAGE_PSE is at the same
> > position as _PAGE_PAT (large pages are using _PAGE_PAT_LARGE instead).
> > 
> > Yes, x86 ABI is a mess.
> 
> Oh, wait: I originally thought _PAGE_CHG_MASK would be used for large pages,
> too. There is _HPAGE_CHG_MASK for that purpose.

Since _HPAGE_CHG_MASK has the _PAGE_PSE aka _PAGE_PAT bit already set, while 
_PAGE_CHK_MASK has not, the real question is not about large pages processing, 
I believe, which won't change whether we add _PAGE_PAT to _PAGE_CHG_MASK or 
not.

If we extend _PAGE_CHG_MASK with _PAGE_PAT bit then its value will be not any 
different from _HPAGE_CHG_MASK.  Then, one may ask why _HPAGE_CHG_MASK, with 
_PAGE_PSE aka PAGE_PAT bit set unlike in _PAGE_CHG_MASK, was introduced once 
for use with large pages, and _PAGE_CHG_MASK left intact for use with standard 
pages, if we now think that adding that bit to _PAGE_CHG_MASK won't break 
processing of standard pages.

If we are sure that adding _PAGE_PAT to _PAGE_CHG_MASK won't break any of its 
users then let's go for it.

Thanks,
Janusz

> 
> So adding _PAGE_PAT to _PAGE_CHG_MASK and _PAGE_PAT_LARGE to _HPAGE_CHG_MASK
> should do the job. At least I hope so.
> 
> 
> Juergen
>