Re: [PATCH 2/2] x86/pat: add functions to query specific cache mode availability

[Chuck Zmudzinski <brchuckz@xxxxxxxxxxxx>]

On 5/3/22 9:22 AM, Juergen Gross wrote:
> Some drivers are using pat_enabled() in order to test availability of
> special caching modes (WC and UC-). This will lead to false negatives
> in case the system was booted e.g. with the "nopat" variant and the
> BIOS did setup the PAT MSR supporting the queried mode, or if the
> system is running as a Xen PV guest.
>
> Add test functions for those caching modes instead and use them at the
> appropriate places.
>
> For symmetry reasons export the already existing x86_has_pat_wp() for
> modules, too.
>
> Fixes: bdd8b6c98239 ("drm/i915: replace X86_FEATURE_PAT with pat_enabled()")
> Fixes: ae749c7ab475 ("PCI: Add arch_can_pci_mmap_wc() macro")
> Signed-off-by: Juergen Gross<jgross@xxxxxxxx>
> ---
>   arch/x86/include/asm/memtype.h           |  2 ++
>   arch/x86/include/asm/pci.h               |  2 +-
>   arch/x86/mm/init.c                       | 25 +++++++++++++++++++++---
>   drivers/gpu/drm/i915/gem/i915_gem_mman.c |  8 ++++----
>   4 files changed, 29 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/include/asm/memtype.h b/arch/x86/include/asm/memtype.h
> index 9ca760e430b9..d00e0be854d4 100644
> --- a/arch/x86/include/asm/memtype.h
> +++ b/arch/x86/include/asm/memtype.h
> @@ -25,6 +25,8 @@ extern void memtype_free_io(resource_size_t start, 
> resource_size_t end);
>   extern bool pat_pfn_immune_to_uc_mtrr(unsigned long pfn);
>   
>   bool x86_has_pat_wp(void);
> +bool x86_has_pat_wc(void);
> +bool x86_has_pat_uc_minus(void);
>   enum page_cache_mode pgprot2cachemode(pgprot_t pgprot);
>   
>   #endif /* _ASM_X86_MEMTYPE_H */
> diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
> index f3fd5928bcbb..a5742268dec1 100644
> --- a/arch/x86/include/asm/pci.h
> +++ b/arch/x86/include/asm/pci.h
> @@ -94,7 +94,7 @@ int pcibios_set_irq_routing(struct pci_dev *dev, int pin, int 
> irq);
>   
>   
>   #define HAVE_PCI_MMAP
> -#define arch_can_pci_mmap_wc() pat_enabled()
> +#define arch_can_pci_mmap_wc() x86_has_pat_wc()
>   #define ARCH_GENERIC_PCI_MMAP_RESOURCE
>   
>   #ifdef CONFIG_PCI
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index 71e182ebced3..b6431f714dc2 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -77,12 +77,31 @@ static uint8_t __pte2cachemode_tbl[8] = {
>         [__pte2cm_idx(_PAGE_PWT | _PAGE_PCD | _PAGE_PAT)] = _PAGE_CACHE_MODE_UC,
>   };
>   
> -/* Check that the write-protect PAT entry is set for write-protect */
> +static bool x86_has_pat_mode(unsigned int mode)
> +{
> +       return __pte2cachemode_tbl[__cachemode2pte_tbl[mode]] == mode;
> +}
> +
> +/* Check that PAT supports write-protect */
>   bool x86_has_pat_wp(void)
>   {
> -       return __pte2cachemode_tbl[__cachemode2pte_tbl[_PAGE_CACHE_MODE_WP]] ==
> -              _PAGE_CACHE_MODE_WP;
> +       return x86_has_pat_mode(_PAGE_CACHE_MODE_WP);
> +}
> +EXPORT_SYMBOL_GPL(x86_has_pat_wp);
> +
> +/* Check that PAT supports WC */
> +bool x86_has_pat_wc(void)
> +{
> +       return x86_has_pat_mode(_PAGE_CACHE_MODE_WC);
> +}
> +EXPORT_SYMBOL_GPL(x86_has_pat_wc);
> +
> +/* Check that PAT supports UC- */
> +bool x86_has_pat_uc_minus(void)
> +{
> +       return x86_has_pat_mode(_PAGE_CACHE_MODE_UC_MINUS);
>   }
> +EXPORT_SYMBOL_GPL(x86_has_pat_uc_minus);
>   
>   enum page_cache_mode pgprot2cachemode(pgprot_t pgprot)
>   {
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index 0c5c43852e24..f43ecf3f63eb 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -76,7 +76,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
>         if (args->flags & ~(I915_MMAP_WC))
>                 return -EINVAL;
>   
> -	if (args->flags & I915_MMAP_WC && !pat_enabled())
> +       if (args->flags & I915_MMAP_WC && !x86_has_pat_wc())
>                 return -ENODEV;
>   
>   	obj = i915_gem_object_lookup(file, args->handle);
> @@ -757,7 +757,7 @@ i915_gem_dumb_mmap_offset(struct drm_file *file,
>   
>   	if (HAS_LMEM(to_i915(dev)))
>                 mmap_type = I915_MMAP_TYPE_FIXED;
> -       else if (pat_enabled())
> +       else if (x86_has_pat_wc())
>                 mmap_type = I915_MMAP_TYPE_WC;
>         else if (!i915_ggtt_has_aperture(to_gt(i915)->ggtt))
>                 return -ENODEV;
> @@ -813,7 +813,7 @@ i915_gem_mmap_offset_ioctl(struct drm_device *dev, void 
> *data,
>                 break;
>   
>   	case I915_MMAP_OFFSET_WC:
> -               if (!pat_enabled())
> +               if (!x86_has_pat_wc())
>                         return -ENODEV;
>                 type = I915_MMAP_TYPE_WC;
>                 break;
> @@ -823,7 +823,7 @@ i915_gem_mmap_offset_ioctl(struct drm_device *dev, void 
> *data,
>                 break;
>   
>   	case I915_MMAP_OFFSET_UC:
> -               if (!pat_enabled())
> +               if (!x86_has_pat_uc_minus())
>                         return -ENODEV;
>                 type = I915_MMAP_TYPE_UC;
>                 break;
This patch is advertised as a fix for
bdd8b6c98239 ("drm/i915: replace X86_FEATURE_PAT with pat_enabled()")

bdd8b6c98239 causes a serious regression on my system when
running Linux as a Dom0 on Xen.

The regression is that on my system, the error caused by this issue
causes the i915driver to call its add_taint_for_CI function, which
in turn totally halts the system during early boot. So this makes
it impossible for either 5.17.y or the 5.18-rc versions to run
as a Dom0 on my system. I cannot upgrade my system to the 5.17.y
or to 5.18-rc versions without a proper fix for bdd8b6c98239.

I did some testing with this patch on my system (my tests included
the first patch of this 2-patch series), and here are the results:

This patch does *not* fix it. I expected this patch, as is, to not
fix it but allow me to add a simple patch that uses the new
x86_has_pat_wc() function provided by this patch to the
i915_gem_object_pin_map() function in i915_gem_pages.c
that would fix it.

However, even by adding the following simple patch to the
i915_gem_object_pin_map() function to the patch, the
patch series still does *not* fix the regression on my system:

--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -428,7 +428,7 @@
             goto err_unpin;
         }

-        if (GEM_WARN_ON(type == I915_MAP_WC && !pat_enabled()))
+        if (GEM_WARN_ON(type == I915_MAP_WC && !x86_has_pat_wc()))
             ptr = ERR_PTR(-ENODEV);
         else if (i915_gem_object_has_struct_page(obj))
             ptr = i915_gem_object_map_page(obj, type);

I verified that this is the function where pat_enabled() is returning
a false negative on my system.

This means x86_has_pat_wc() is still giving me a false negative, even
when running as a Xen Dom0. I am not sure you understand what is
really causing the problem Jan is trying to fix here with false
negatives from pat_enabled(). I also tested Jan's patch that
you are trying to replace with this patch, and his patch *does* fix
the problem on my system. Jan's patch is very simple and solves the
problem by editing pat_enabled() so that it returns true if
boot_cpu_has(X86_FEATURE_HYPERVISOR)) is true after the
other checks for the x86 pat feature failed.

I expect you do not have a system that actually has the problem
that Jan and I are trying to fix because the problem only exists on
systems with specific hardware, and in my case it is an Intel Haswell
CPU with integrated GPU. You might be able to test your patch,
though, if you boot the patched kernel with the nopat option and
check if your new functions return false when running on the bare
metal and true when running in a Dom0 on the Xen hypervisor. That is
what the new functions should do. I think you were expecting your
new x86_has_pat_wc() function to return true when Linux is running
as a Dom0 on the Xen hypervisor even when pat_enabled() returns
false. But it does not seem to be working.

In any case, after testing this patch, I cannot confirm that it
fixes bdd8b6c98239.

Best regards,

Chuck