On 5 June 2018 at 10:54, Laszlo Ersek <ler...@redhat.com> wrote: > On 06/05/18 10:23, Ard Biesheuvel wrote: >> On 5 June 2018 at 10:18, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: >>> On 5 June 2018 at 10:16, Laszlo Ersek <ler...@redhat.com> wrote: > >>>> To my understanding, Daniel has the opposite preference; namely, the >>>> above approach doesn't scale to a large and moving target like the >>>> kernel. Because the instructions in question work on the bare metal >>>> (IOW, the guest code is not "broken" in any sense of the word), people >>>> will continue writing kernel MMIO code in C that "lures" gcc into >>>> generating such ARM/AArch64 assembly that contains those instructions. >>>> >> >> Kernel MMIO code is not written in C, it used readl/writel and friends. > > Are we certain that all drivers, and all platform MMIO code, use > readl/writel? > >>>> Your edk2 ArmVirtQemu patch adds a heavy-weight flag (-fno-lto) to a >>>> pin-point location; another possibility (that might scale better to >>>> humans) is a new, lighter-weight flag, such as "-mno-multiple", that is >>>> applied universally to a codebase. >>>> >>> >>> That will affect *all* memory references, which will undoubtedly hurt >>> performance. >> >> ... given that it will prevent us from using load/store pair >> instructions, which are used *everywhere*. Every function prologue >> consists of a collection of ldp instructions, every function epilogue >> has stp instructions. Optimized copy routines use ldp/stp as well. >> >> So rebuilding the world with -mno-multiple is not going to fly, really. >> >> We should probably start with improving the diagnostics produced by >> KVM when this situation hits. > > That would indeed speed up things, on the analysis side. > >> And given that this is (imo) a bug in >> the architecture, it should be up to KVM to work around it. > > I've had a similar idea (not sure how correct I am to call it "similar", > let me say it is "related to virtualization" at the least) -- AIUI there > are various "paravirt ops" in the kernel, and readl/writel could be "KVM > friendly" when the kernel realizes it runs under KVM. Sorry if this is a > totally bogus idea; regardless, even if we did something similar at > build time that *only* penalized readl/writel (and not function > prologues, epilogues, or copy routines), the issue would remain whether > all drivers and platform MMIO code restricted themselves to readl/writel. >
The more I look into the BZ you quoted, the more I think the multiple register thing is a red herring (in the conetext of that bug, mind you) I replied (and am about to reply again) there. https://bugzilla.redhat.com/show_bug.cgi?id=1576593
