Re: [RFC PATCH 8/8] Use Linux's PAT

[Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>]

On Tue, Dec 06, 2022 at 07:12:06PM +0100, Marek Marczykowski-Górecki wrote:
> On Tue, Dec 06, 2022 at 01:01:41PM -0500, Demi Marie Obenour wrote:
> > On Tue, Dec 06, 2022 at 11:38:03AM +0000, Andrew Cooper wrote:
> > > On 06/12/2022 04:33, Demi Marie Obenour wrote:
> > > > This is purely for testing, to see if it works around a bug in i915.  It
> > > > is not intended to be merged.
> > > >
> > > > NOT-signed-off-by: DO NOT MERGE
> > > 
> > > Following up on Marek's report on IRC/Matrix, you're saying that this
> > > change does actually fix screen corruption issues on AlderLake, and
> > > something on TigerLake too?
> > 
> > Correct
> > 
> > > If that is actually the case, then one of two things is happening.  
> > > Either,
> > > 
> > > 1) Drivers in Linux are bypassing the regular caching APIs, or
> > 
> > This would not surprise me at all.
> > 
> > > 2) The translation logic between Linux's idea of cacheability and Xen's
> > > PAT values is buggy.
> > 
> > How could I check for this?
> 
> See Andy's unit test idea on #xendevel:
> 
>     as a pretty simple "unit" test in dom0, it might be a good idea to
>     have a module which watches the PTE in question, and cycles through
>     various of the memremap_*() APIs and checks the raw PTE that gets
>     written after Linux and Xen are done fighting with it

This confirmed that the translation logic is correct, which means that
i195 is buggy.  I filed https://gitlab.freedesktop.org/drm/intel/-/issues/7648
for that.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

Attachment: signature.asc
Description: PGP signature