Message ID | 20230609130140.182781-2-janusz.krzysztofik@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp941301vqr; Fri, 9 Jun 2023 06:18:03 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5oyaHBS394h4Jq8rIZFucPLc0x87l8o5/8p2AiUz/BiDkTTz2bOPY7jn7f904jrOQxR6Y9 X-Received: by 2002:a17:903:294c:b0:1ae:5c72:d63c with SMTP id li12-20020a170903294c00b001ae5c72d63cmr916088plb.11.1686316683047; Fri, 09 Jun 2023 06:18:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686316683; cv=none; d=google.com; s=arc-20160816; b=dSKXAPKeE/AtDP3ErxW/MhPM3nqazak3LcNZsnCBXrd1IMGllgnYvvE9xZG74ryMRG mPX9aOuuESGruD0fM6Fl9PE6/Ue9iGd14RIHICYEPs9znWHuGJhjmmWAOggSqkhJEs7X F3KX596j5mi2Imyk6El+zczkzi3UE5a3H/qoR7lirVQAizu9V3q1uC/9Xka2SKmG/WTJ NRrU/LPHXJnp76lRNktN5xFqvV+Xq59Ub0ayRv1NGZmXPEQstrmk3PTT6B+TBIWAy27X kEFqkkqoW2mFAbpG+sZRgIGttrzWpC/VfDA262OcmesJ1ZiM97+sGhTwLYTNX/UIMqU/ a0vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=5TC3TPzzNTNdtsUDFLRjmsa2Txr6pAR3yr7CRt6iS7A=; b=kZllSbsZvmYeAFe7N0wFAeNAM4xN5rgNYDvPtgfEkUM8DDxuXsXNLrZorwZFBX/Lf9 zQTnGQrZRrFNWEjOTW+3oLeTs7see8p/bpSjh6k0UptONvqRwEQ8Kt1hEs9sC6WVzyXj UC/4Kxz3R3thiRIGi3xDrhbfke6Mby5xo6smR1jDvGE4wRxpzUNXQxZfz35WpFK8zmY0 4Nh3QYlM4Q7mlnn90ylom0IYEds6VzGVkyNG1BlCrf2WoT5seiHAuur+qJa/eS869upE PrmYqE3eWxlLNMJthSu6p0fIdvsDfsoINXCWo6/NLCZbB/r6Uu5ufNlH7nxQZMup38Pj RCug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=FmH19j6Y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 12-20020a170902e9cc00b001b05ca04190si2725763plk.65.2023.06.09.06.17.47; Fri, 09 Jun 2023 06:18:02 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=FmH19j6Y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232327AbjFIND0 (ORCPT <rfc822;liningstudo@gmail.com> + 99 others); Fri, 9 Jun 2023 09:03:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33000 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229903AbjFINDY (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 9 Jun 2023 09:03:24 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 61C782D70 for <linux-kernel@vger.kernel.org>; Fri, 9 Jun 2023 06:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1686315803; x=1717851803; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=B9j6KPnGI5sD7s8Q0BlmWPjFLlcPwmzNWwIAy7uvtPw=; b=FmH19j6YEJ0vSLUZwlzBI5MsLcCsQrND+BNjCnj1Ni4evGsBeV/WjjLB LKiMnGXRifB5Mfsp65gtGZpef6CpDA56MqpQ7NtwWNhTb5bptITeLXw6W FZrAF3e2fILPhnABOkB16h0Jey4w4m2iIcGPbCk/ibTX0bIF2PzBe+FMq vetEtBD8Mk3EyPK2O4cSSX+tRZtR+Do6u0X4pq/5NlFp4r5yKwY+DAo/A waFPnX2ms0rNY6NJRvS4jRNsnqO4+SJ5ZGd/ZUW1S0g41aM5erTTspOeu HKciJBTmYLFpjxoesbK115BK5WQGRxZzyNu+B50xASOzKh4k8Sx4JiBMX g==; X-IronPort-AV: E=McAfee;i="6600,9927,10736"; a="337226251" X-IronPort-AV: E=Sophos;i="6.00,229,1681196400"; d="scan'208";a="337226251" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jun 2023 06:03:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10736"; a="710356718" X-IronPort-AV: E=Sophos;i="6.00,229,1681196400"; d="scan'208";a="710356718" Received: from pdrab-mobl1.ger.corp.intel.com (HELO jkrzyszt-mobl2.ger.corp.intel.com) ([10.213.11.29]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jun 2023 06:03:19 -0700 From: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> To: Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com> Cc: Juergen Gross <jgross@suse.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>, linux-kernel@vger.kernel.org, Andi Shyti <andi.shyti@linux.intel.com>, intel-gfx@lists.freedesktop.org, =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>, Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Subject: [PATCH v3] x86/mm: Fix PAT bit missing from page protection modify mask Date: Fri, 9 Jun 2023 15:01:41 +0200 Message-ID: <20230609130140.182781-2-janusz.krzysztofik@linux.intel.com> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_PASS, SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1768231202120654773?= X-GMAIL-MSGID: =?utf-8?q?1768231202120654773?= |
Series |
[v3] x86/mm: Fix PAT bit missing from page protection modify mask
|
|
Commit Message
Janusz Krzysztofik
June 9, 2023, 1:01 p.m. UTC
Visible glitches have been observed when running graphics applications on Linux under Xen hypervisor. Those observations have been confirmed with failures from kms_pwrite_crc Intel GPU test that verifies data coherency of DRM frame buffer objects using hardware CRC checksums calculated by display controllers, exposed to userspace via debugfs. Affected processing paths have then been identified with new IGT test variants that mmap the objects using different methods and caching modes [1]. When running as a Xen PV guest, Linux uses Xen provided PAT configuration which is different from its native one. In particular, Xen specific PTE encoding of write-combining caching, likely used by graphics applications, differs from the Linux default one found among statically defined minimal set of supported modes. Since Xen defines PTE encoding of the WC mode as _PAGE_PAT, it no longer belongs to the minimal set, depends on correct handling of _PAGE_PAT bit, and can be mismatched with write-back caching. When a user calls mmap() for a DRM buffer object, DRM device specific .mmap file operation, called from mmap_region(), takes care of setting PTE encoding bits in a vm_page_prot field of an associated virtual memory area structure. Unfortunately, _PAGE_PAT bit is not preserved when the vma's .vm_flags are then applied to .vm_page_prot via vm_set_page_prot(). Bits to be preserved are determined with _PAGE_CHG_MASK symbol that doesn't cover _PAGE_PAT. As a consequence, WB caching is requested instead of WC when running under Xen (also, WP is silently changed to WT, and UC downgraded to UC_MINUS). When running on bare metal, WC is not affected, but WP and WT extra modes are unintentionally replaced with WC and UC, respectively. WP and WT modes, encoded with _PAGE_PAT bit set, were introduced by commit 281d4078bec3 ("x86: Make page cache mode a real type"). Care was taken to extend _PAGE_CACHE_MASK symbol with that additional bit, but that symbol has never been used for identification of bits preserved when applying page protection flags. Support for all cache modes under Xen, including the problematic WC mode, was then introduced by commit 47591df50512 ("xen: Support Xen pv-domains using PAT"). The issue needs to be fixed by including _PAGE_PAT bit into a bitmask used by pgprot_modify() for selecting bits to be preserved. We can do that either internally to pgprot_modify() (as initially proposed), or by making _PAGE_PAT a part of _PAGE_CHG_MASK. If we go for the latter then, since _PAGE_PAT is the same as _PAGE_PSE, we need to note that _HPAGE_CHG_MASK -- a huge pmds' counterpart of _PAGE_CHG_MASK, introduced by commit c489f1257b8c ("thp: add pmd_modify"), defined as (_PAGE_CHG_MASK | _PAGE_PSE) -- will no longer differ from _PAGE_CHG_MASK. If such modification of _PAGE_CHG_MASK was irrelevant to its users then one might wonder why that new _HPAGE_CHG_MASK symbol was introduced instead of reusing the existing one with that otherwise irrelevant bit (_PAGE_PSE in that case) added. Assume that adding _PAGE_PAT to _PAGE_CHG_MASK doesn't break pte_modify() and its users, and go for it. Also, add _PAGE_PAT_LARGE to _HPAGE_CHG_MASK for symmetry. For better clarity, split out common bits from both symbols to another one and use it together with specific bits when defining the masks. v3: Separate out common bits of _PAGE_CHG_MASK and _HPAGE_CHG_MASK into _COMMON_PAGE_CHG_MASK (Rick), - fix hard to parse wording of 'what' part of commit description (on Dave's request). v2: Keep pgprot_modify() untouched, make _PAGE_PAT part of _PAGE_CHG_MASK instead (Borislav), - also add _PAGE_PAT_LARGE to _HPAGE_CHG_MASK (Juergen). [1] https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/commit/0f0754413f14 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7648 Fixes: 281d4078bec3 ("x86: Make page cache mode a real type") Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Acked-by: Juergen Gross <jgross@suse.com> # v1 Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@intel.com> Cc: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com> Cc: stable@vger.kernel.org # v3.19+ --- arch/x86/include/asm/pgtable_types.h | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
Comments
On 09.06.23 15:01, Janusz Krzysztofik wrote: > Visible glitches have been observed when running graphics applications on > Linux under Xen hypervisor. Those observations have been confirmed with > failures from kms_pwrite_crc Intel GPU test that verifies data coherency > of DRM frame buffer objects using hardware CRC checksums calculated by > display controllers, exposed to userspace via debugfs. Affected > processing paths have then been identified with new IGT test variants that > mmap the objects using different methods and caching modes [1]. > > When running as a Xen PV guest, Linux uses Xen provided PAT configuration > which is different from its native one. In particular, Xen specific PTE > encoding of write-combining caching, likely used by graphics applications, > differs from the Linux default one found among statically defined minimal > set of supported modes. Since Xen defines PTE encoding of the WC mode as > _PAGE_PAT, it no longer belongs to the minimal set, depends on correct > handling of _PAGE_PAT bit, and can be mismatched with write-back caching. > > When a user calls mmap() for a DRM buffer object, DRM device specific > .mmap file operation, called from mmap_region(), takes care of setting PTE > encoding bits in a vm_page_prot field of an associated virtual memory area > structure. Unfortunately, _PAGE_PAT bit is not preserved when the vma's > .vm_flags are then applied to .vm_page_prot via vm_set_page_prot(). Bits > to be preserved are determined with _PAGE_CHG_MASK symbol that doesn't > cover _PAGE_PAT. As a consequence, WB caching is requested instead of WC > when running under Xen (also, WP is silently changed to WT, and UC > downgraded to UC_MINUS). When running on bare metal, WC is not affected, > but WP and WT extra modes are unintentionally replaced with WC and UC, > respectively. > > WP and WT modes, encoded with _PAGE_PAT bit set, were introduced by commit > 281d4078bec3 ("x86: Make page cache mode a real type"). Care was taken > to extend _PAGE_CACHE_MASK symbol with that additional bit, but that > symbol has never been used for identification of bits preserved when > applying page protection flags. Support for all cache modes under Xen, > including the problematic WC mode, was then introduced by commit > 47591df50512 ("xen: Support Xen pv-domains using PAT"). > > The issue needs to be fixed by including _PAGE_PAT bit into a bitmask used > by pgprot_modify() for selecting bits to be preserved. We can do that > either internally to pgprot_modify() (as initially proposed), or by making > _PAGE_PAT a part of _PAGE_CHG_MASK. If we go for the latter then, since > _PAGE_PAT is the same as _PAGE_PSE, we need to note that _HPAGE_CHG_MASK > -- a huge pmds' counterpart of _PAGE_CHG_MASK, introduced by commit > c489f1257b8c ("thp: add pmd_modify"), defined as (_PAGE_CHG_MASK | > _PAGE_PSE) -- will no longer differ from _PAGE_CHG_MASK. If such > modification of _PAGE_CHG_MASK was irrelevant to its users then one might > wonder why that new _HPAGE_CHG_MASK symbol was introduced instead of > reusing the existing one with that otherwise irrelevant bit (_PAGE_PSE in > that case) added. > > Assume that adding _PAGE_PAT to _PAGE_CHG_MASK doesn't break pte_modify() > and its users, and go for it. Also, add _PAGE_PAT_LARGE to > _HPAGE_CHG_MASK for symmetry. For better clarity, split out common bits > from both symbols to another one and use it together with specific bits > when defining the masks. > > v3: Separate out common bits of _PAGE_CHG_MASK and _HPAGE_CHG_MASK into > _COMMON_PAGE_CHG_MASK (Rick), > - fix hard to parse wording of 'what' part of commit description (on > Dave's request). > v2: Keep pgprot_modify() untouched, make _PAGE_PAT part of _PAGE_CHG_MASK > instead (Borislav), > - also add _PAGE_PAT_LARGE to _HPAGE_CHG_MASK (Juergen). > > [1] https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/commit/0f0754413f14 > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7648 > Fixes: 281d4078bec3 ("x86: Make page cache mode a real type") > Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> > Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> > Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> > Acked-by: Juergen Gross <jgross@suse.com> # v1 > Cc: Borislav Petkov <bp@alien8.de> > Cc: Dave Hansen <dave.hansen@intel.com> > Cc: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com> > Cc: stable@vger.kernel.org # v3.19+ Reviewed-by: Juergen Gross <jgross@suse.com> Juergen
diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h index 447d4bee25c48..97533e6b1c61b 100644 --- a/arch/x86/include/asm/pgtable_types.h +++ b/arch/x86/include/asm/pgtable_types.h @@ -125,11 +125,12 @@ * instance, and is *not* included in this mask since * pte_modify() does modify it. */ -#define _PAGE_CHG_MASK (PTE_PFN_MASK | _PAGE_PCD | _PAGE_PWT | \ - _PAGE_SPECIAL | _PAGE_ACCESSED | _PAGE_DIRTY | \ - _PAGE_SOFT_DIRTY | _PAGE_DEVMAP | _PAGE_ENC | \ - _PAGE_UFFD_WP) -#define _HPAGE_CHG_MASK (_PAGE_CHG_MASK | _PAGE_PSE) +#define _COMMON_PAGE_CHG_MASK (PTE_PFN_MASK | _PAGE_PCD | _PAGE_PWT | \ + _PAGE_SPECIAL | _PAGE_ACCESSED | _PAGE_DIRTY |\ + _PAGE_SOFT_DIRTY | _PAGE_DEVMAP | _PAGE_ENC | \ + _PAGE_UFFD_WP) +#define _PAGE_CHG_MASK (_COMMON_PAGE_CHG_MASK | _PAGE_PAT) +#define _HPAGE_CHG_MASK (_COMMON_PAGE_CHG_MASK | _PAGE_PSE | _PAGE_PAT_LARGE) /* * The cache modes defined here are used to translate between pure SW usage