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

[Laszlo Ersek <lersek at redhat dot com>]

On 06/05/18 10:56, Ard Biesheuvel wrote:
> 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
> 

Thank you for helping out with it!
Laszlo