Re: [PATCH v7 4/4] x86: Allow using Linux's PAT

[Jan Beulich <jbeulich@xxxxxxxx>]

On 07.01.2023 23:07, Demi Marie Obenour wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -227,6 +227,39 @@ config XEN_ALIGN_2M
>  
>  endchoice
>  
> +config LINUX_PAT
> +     bool "Use Linux's PAT instead of Xen's default"
> +     help
> +       Use Linux's Page Attribute Table instead of the default Xen value.
> +
> +       The Page Attribute Table (PAT) maps three bits in the page table entry
> +       to the actual cacheability used by the processor.  Many Intel
> +       integrated GPUs have errata (bugs) that cause CPU access to GPU memory
> +       to ignore the topmost bit.  When using Xen's default PAT, this results
> +       in caches not being flushed and incorrect images being displayed.  The
> +       default PAT used by Linux does not cause this problem.
> +
> +       If you say Y here, you will be able to use Intel integrated GPUs that
> +       are attached to your Linux dom0 or other Linux PV guests.  However,
> +       you will not be able to use non-Linux OSs in dom0, and attaching a PCI
> +       device to a non-Linux PV guest will result in unpredictable guest
> +       behavior.  If you say N here, you will be able to use a non-Linux
> +       dom0, and will be able to attach PCI devices to non-Linux PV guests.
> +
> +       Note that saving a PV guest with an assigned PCI device on a machine
> +       with one PAT and restoring it on a machine with a different PAT won't
> +       work: the resulting guest may boot and even appear to work, but caches
> +       will not be flushed when needed, with unpredictable results.  HVM
> +       (including PVH and PVHVM) guests and guests without assigned PCI
> +       devices do not care what PAT Xen uses, and migration (even live)
> +       between hypervisors with different PATs will work fine.  Guests using
> +       PV Shim care about the PAT used by the PV Shim firmware, not the
> +       host’s PAT.  Also, non-default PAT values are incompatible with the
> +       (deprecated) qemu-traditional stubdomain.
> +
> +       Say Y if you are building a hypervisor for a Linux distribution that
> +       supports Intel iGPUs.  Say N otherwise.

I'm not convinced we want this; if other maintainers think differently,
then I don't mean to stand in the way though. If so, however,
- the above likely wants guarding by EXPERT and/or UNSUPPORTED
- the support status of using this setting wants to be made crystal
  clear, perhaps by an addition to ./SUPPORT.md.

Jan