public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Laszlo Ersek <lersek@redhat.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	Leif Lindholm <leif.lindholm@linaro.org>
Subject: Re: [PATCH] ArmVirtPkg/ArmVirtQemu ARM: work around KVM limitations in LTO build
Date: Mon, 4 Jun 2018 17:30:27 +0200	[thread overview]
Message-ID: <CAKv+Gu_f3u8ZNWk3Httqi0ciJ5FVWdffqBS5g4sMHp-CTVGQ=g@mail.gmail.com> (raw)
In-Reply-To: <a43abf5a-f5fd-3688-ed26-3b111d766719@redhat.com>

On 4 June 2018 at 17:18, Laszlo Ersek <lersek@redhat.com> wrote:
> On 06/04/18 16:50, Ard Biesheuvel wrote:
>> KVM on ARM refuses to decode load/store instructions used to perform
>> I/O to emulated devices, and instead relies on the exception syndrome
>> information to describe the operand register, access size, etc.
>> This is only possible for instructions that have a single input/output
>> register (as opposed to ones that increment the offset register, or
>> load/store pair instructions, etc). Otherwise, QEMU crashes with the
>> following error
>>
>>   error: kvm run failed Function not implemented
>>   R00=01010101 R01=00000008 R02=00000048 R03=08000820
>>   R04=00000120 R05=7faaa0e0 R06=7faaa0dc R07=7faaa0e8
>>   R08=7faaa0ec R09=7faaa088 R10=000000ff R11=00000080
>>   R12=ff000000 R13=7fccfe08 R14=7faa835f R15=7faa887c
>>   PSR=800001f3 N--- T svc32
>>   QEMU: Terminated
>>
>> and KVM produces a warning such as the following in the kernel log
>>
>>   kvm [17646]: load/store instruction decoding not implemented
>>
>> GCC with LTO enabled will emit such instructions for Mmio[Read|Write]
>> invocations performed in a loop, so we need to disable LTO for the
>> IoLib library to ensure that the emitted instructions are suitable for
>> emulated I/O under KVM
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>>  ArmVirtPkg/ArmVirtQemu.dsc | 18 ++++++++++++++++++
>>  1 file changed, 18 insertions(+)
>>
>> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
>> index d74feb709cd1..e6e3d82d6ca9 100644
>> --- a/ArmVirtPkg/ArmVirtQemu.dsc
>> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
>> @@ -414,3 +414,21 @@ [Components.AARCH64]
>>      <LibraryClasses>
>>        NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
>>    }
>> +
>> +[Components.ARM]
>> +  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf {
>> +    <BuildOptions>
>> +      //
>> +      // KVM on ARM refuses to decode load/store instructions used to perform
>> +      // I/O to emulated devices, and instead relies on the exception syndrome
>> +      // information to describe the operand register, access size, etc.
>> +      // This is only possible for instructions that have a single input/output
>> +      // register (as opposed to ones that increment the offset register, or
>> +      // load/store pair instructions, etc).
>> +      // GCC with LTO enabled will emit such instructions for Mmio[Read|Write]
>> +      // invocations performed in a loop, so we need to disable LTO for this
>> +      // library to ensure that the emitted instructions are suitable for
>> +      // emulated I/O under KVM
>> +      //
>> +      GCC:*_GCC5_ARM_CC_FLAGS = -fno-lto
>> +  }
>>
>
> Heh :) See <https://bugzilla.redhat.com/show_bug.cgi?id=1576593>.
>
> - Is there perhaps a finer-grained GCC option for this? (This is a
> rhetorical question; I know you must have checked.)
>

Unfortunately not. That is why this is a workaround rather than a fix.

> - Is this only with gcc-8?
>

I don't think so. Any GCC/GNU-ld combo that supports LTO is
susceptible to this afaik. Even worse, I don't think this is limited
to 32-bit ARM either, even if we've never managed to hit it.

> - Should we do the same for the ArmVirtXen and ArmVirtQemuKernel
> platforms? In turn, patch "ArmVirt.dsc.inc" instead? (BTW I have no clue
> about Xen's emulation of the instructions at hand.)
>

This is a fix I would like to apply with moderation, so that we get a
feeling for which platforms need it and which don't.

ArmVirtQemuKernel is primarily used in TCG mode, as far as I am aware,
by the OP-TEE guys for instance, who use secure world emulation.

Xen doesn't really use I/O emulation on ARM (everything is
paravirtualized) so I don't think it is affected.

> In general, I'm fine with the patch. According to [1] [2], this appears
> to be the right syntax for the goal.
>

Thanks,


  reply	other threads:[~2018-06-04 15:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-04 14:50 [PATCH] ArmVirtPkg/ArmVirtQemu ARM: work around KVM limitations in LTO build Ard Biesheuvel
2018-06-04 15:18 ` Laszlo Ersek
2018-06-04 15:30   ` Ard Biesheuvel [this message]
2018-06-04 15:34     ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKv+Gu_f3u8ZNWk3Httqi0ciJ5FVWdffqBS5g4sMHp-CTVGQ=g@mail.gmail.com' \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox