Re: code-gen options for disabling multi-operand AArch64 and ARM instructions

[Ard Biesheuvel <ard dot biesheuvel at linaro dot org>]

On 5 June 2018 at 10:54, Laszlo Ersek <lersek@redhat.com> wrote:
> On 06/05/18 10:23, Ard Biesheuvel wrote:
>> On 5 June 2018 at 10:18, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>> On 5 June 2018 at 10:16, Laszlo Ersek <lersek@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