Re: runtime regression with "x86/mm/pat: Emulate PAT when it is disabled"

[Toshi Kani]

On Thu, 2016-03-03 at 15:59 -0500, Paul Gortmaker wrote:
> So, the yocto folks moved from 4.1 to 4.4 and one of their automated
> qemu x86-32 boot tests started failing.ÂÂNone of the yocto details seem
> to matter since I offered to help and I've repropduced it using 100%
> mainline kernels and a generic distro toolchain as well.
> 
> The test case is slightly complicated, in that it relies on uvesafb
> being modular, and so one has to juggle modules within an ext4 image
> that qemu boots from.ÂÂWe tried making uvesafb builtin, but that made
> the issue magically vanish.ÂÂGiven PAT, this isn't too surprising.
> 
> Richard did the preliminary investigation and analysis, and from that I
> did a bisect, and found the commit in $SUBJECT to be the root cause, as
> per the discussion here:
> 
> http://lists.openembedded.org/pipermail/openembedded-core/2016-March/1183
> 97.html
> 
> I'd mentioned the above to bpetkov on IRC and after confirming it was
> still an issue on 4.5-rc6, he'd asked if I had a portable reproducer.ÂÂ
> 
> Not sure how complicated that would be, I set out to make one from my
> build.ÂÂÂWith a little LD_PRELOAD type magic and ensuring all the qemu
> components are in ./ÂÂI have one that runs on an otherwise qemu-free
> x86-64 box.Â
> 
> The stand alone reproducer is here; launched in 00-runme:
> 
> http://openlinux.wrs.com/pat-splat/reproducer.tar.bz2ÂÂ;
> 
> It is nothing fancy, just a generic yocto build of "sato" (gfx enabled
> rootfs).ÂÂWhen it "works" it boots to a UI touchscreen interface.ÂÂWhen
> it fails, you get a black screen with a blinking cursor (as seen in
> "vncviewer localhost:0").

Thanks for tracking down, and packaging the reproducer. ÂI simply untar'd
and ran 00-runme, but was not able to connect with localhost:0. ÂI am not
familiar with qemu, so I have not looked into why, though...

Anyway, with regarding the error message:
 "x86/PAT: Xorg:705 map pfn expected mapping type uncached-minus for [mem
0xfd000000-0xfdffffff], got write-combining"

Did it came from the following path during fork()?
Âcopy_process
 copy_mm
 Âdup_mm
  dup_mmap
  Âcopy_page_range
   track_pfn_copy
   Âreserve_pfn_range

If so, track_pfn_copy() obtained pgprot from a PTE, and called
reserve_pfn_range() with it. ÂSo, the error message indicates that previous
ioremap_wc() (i.e. pcm WC) resulted in creating UC- map (i.e. pgprot UC-).
Âpcm is a logical cache type and pgprot is a HW cache type. ÂThey can be
different when CPU does not have support for a given logical type. ÂThis WC
to UC- conversion happens when CPU does not support PAT.

Richard's change, which compares with pgprot values in reserve_pfn_range()
is a good one, but I do not understand how we get into this mess. ÂWe do
not have this check when PAT is disabled, and WC is supported when PAT is
enabled.

CommitÂ9cd25aac1 changed the initial values of the pcm<->pgrot conversion
tables. ÂThe tables should be initialized with the same values after
pat_init() is called. ÂIs there any possibility that ioremap_wc() was
called before pat_init()..?

Also, can you send me a whole dmesg output? ÂI'd like to check how PAT is
initialized.

Thanks!
-Toshi