On 06/05/18 10:56, Ard Biesheuvel wrote: > 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 >
Thank you for helping out with it! Laszlo
