> On Mar 11, 2018, at 12:51 PM, Nick French <naf@xxxxxx> wrote: > > On Sat, Mar 10, 2018 at 10:20:23AM -0800, Andy Lutomirski wrote: >>>> Perhaps the easy answer is to change the fatal is-pat-enabled check to just >>>> a warning like "you have PAT enabled, so wc is disabled for the framebuffer. >>>> if you want wc, use the nopat parameter"? >>> >>> I like this idea more and more. I haven't experience any problems running >>> with PAT-enabled and no write-combining on the framebuffer. Any objections? >>> >> >> None from me. >> >> However, since you have the hardware, you could see if you can use the >> change_page_attr machinery to change the memory type on the framebuffer once >> you figure out where it is. > > I am certainly willing to try this, but my understanding of the goal of the > changes that disabled ivtvfb originally is that it was trying to hide the > architecture-specific memory management from the driver. Not really. The goal was to eliminate all code that touches MTRRs on PAT systems. So mtrr_add got unexported and the arch_phys are legacy hints that do nothing on modern machines. > > Wouldn't (figuring out a way to) expose x86/mm/pageattr internals to the > driver be doing the opposite? (or maybe I misunderstand your suggestion) It doesn’t conflict at all. Obviously the code should be tidy. >From memory, I see two potentially reasonable real fixes. One is to find a way to punch a hole in an ioremap. So you’d find the framebuffer, remove it from theproblematic mapping, and then make a new mapping. The second is to change the mapping type in place. Or maybe you could just iounmap the whole thing after firmware is loaded and the framebuffer is found and then redo the mapping right.
