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

[Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>]

On Mon, Jan 09, 2023 at 12:37:34PM +0100, Jan Beulich wrote:
> 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

I considered this, but decided against it.  Recent Intel iGPUs are
simply incompatible with Xen’s default PAT, so anyone wanting to use Xen
in a desktop environment must say Y here.  Guarding this with EXPERT or
UNSUPPORTED will not prevent distribution maintainers from enabling it,
because the alternative is building a hypervisor that does not support
the hardware their users actually have.  Qubes OS is *already* shipping
a patch to use Linux’s PAT, so you don’t need to worry that this code
will go untested.  And if there was a vulnerability that requires
CONFIG_LINUX_PAT=y, I’d rather it not be dropped on Qubes users as a
0day.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

Attachment: signature.asc
Description: PGP signature