On Sat, 14 Jul 2018 06:44:33 +0100 Hazel Russman <hazeldeb...@googlemail.com> wrote:
> I gather that some remapping that used to be done isn't done any more > and that's what my machine doesn't like. Hazel, Congrats! OK, now note the offending commit has two parts: https://patchwork.kernel.org/patch/9847859/ All the second part does is add a warning message and is very unlikely to be the cause of the problem. So, all you have to do to revert to isolate down to 1-2 lines is add two lines to arch/x86/mm/ioremap.c: if (is_ISA_range(phys_addr, last_addr)) return (__force void __iomem *)phys_to_virt(phys_addr); around line 106, just before: /* * Don't allow anybody to remap normal RAM that we're using.. */ pfn = phys_addr >> PAGE_SHIFT; If that fixes 4.15 and later, you've certainly confirmed it all the way down to a line. OK, now get a load of what was said about this commit when it was being reviewed by the kernel developers in June 2017: https://lists.linuxfoundation.org/pipermail/iommu/2017-June/022513.html Particularly the post here: https://lists.linuxfoundation.org/pipermail/iommu/2017-June/022642.html "Making this conditional on !sme_active() is not the best idea. I'd rather remove that whole thing and make it unconditional so the code pathes get always exercised and any subtle wreckage is detected on a broader base and not only on that hard to access and debug SME capable machine owned by Joe User." -- Thomas Gleixner Which means they were/are *expecting* some machines to break because of the change! Here was the original way they considered: if (is_ISA_range(phys_addr, last_addr) && !sme_active()) return (__force void __iomem *)phys_to_virt(phys_addr); The above should also work fine on your system - because the (unwanted/problematic on your machine) remapping later on by ioremap.c will still be *prevented* as long as secure memory encryption is *not* being used. That is - the lines above remaps via phys_to_virt() on machines for ISA range addresses. The code later on in ioremap.c is supposed to be able to handle such re/maps OK with or without SME (without the need to hand things off to phys_to_virt()). If you can confirm restoring the line above fixes the problem, then this is who to report it to: Thomas Gleixner tglx (at) linutronix.de Tom Lendacky thomas.lendacky (at) amd.com Borislav Petkov bp (at) suse.de Possibly all of them as a CC to a post to the Linux IOMMU support mailing list: https://lists.linuxfoundation.org/mailman/listinfo/iommu When they fix it, they will likely do so with *other* changes later on in the ioremap.c code. In other words, the code later in ioremap.c is supposed to work OK on all systems even without the "if (is_ISA_range ..." line. But, since your system is only one that has showed a problem so far, they'll probably want you to run some test code before they decide how best to fix it. And do let us LFS folks know how it turns out. Cheers and thanks, Mike -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
