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. Thanks! Laszlo
