On Tue, Jul 11, 2017 at 4:35 AM, Arnd Bergmann <arnd at arndb.de> wrote: > On Tue, Jul 11, 2017 at 6:58 AM, Brian Gerst <brgerst at gmail.com> wrote: >> On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky <thomas.lendacky at amd.com> wrote: >>> On 7/8/2017 7:57 AM, Brian Gerst wrote: >>>> On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky <thomas.lendacky at amd.com> >>> >>> I originally had a check for SME here in a previous version of the >>> patch. Thomas Gleixner recommended removing the check so that the code >>> path was always exercised regardless of the state of SME in order to >>> better detect issues: >>> >>> http://marc.info/?l=linux-kernel&m=149803067811436&w=2 >> >> Looking a bit closer, this shortcut doesn't set the caching >> attributes. So it's probably best to get rid of it anyways. Also >> note, there is a corresponding check in iounmap(). Perhaps the iounmap() check should be kept for now for safety, since some drivers (vga16fb for example) call iounmap() blindly even if the mapping wasn't returned from ioremap(). Maybe add a warning when an ISA address is passed to iounmap(). > Could that cause regressions if a driver relies on (write-through) > cacheable access to the VGA frame buffer RAM or an read-only > cached access to an option ROM but now gets uncached access? Yes there could be some surprises in drivers use the normal ioremap() call which is uncached but were expecting the default write-through mapping. > I also tried to find out whether we can stop mapping the ISA MMIO > area into the linear mapping, but at least the VGA code uses > VGA_MAP_MEM() to get access to the same pointers. I'm pretty > sure this got copied incorrectly into most other architectures, but > it is definitely still used on x86 with vga16fb/vgacon/mdacon. Changing VGA_MAP_MEM() to use ioremap_wt() would take care of that. Although, looking at the mdacon/vgacon, they don't have support for unmapping the frame buffer if they are built modular. -- Brian Gerst
