From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id CC08A2097215C for ; Mon, 4 Jun 2018 08:34:57 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1AF3F805A530; Mon, 4 Jun 2018 15:34:57 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-232.rdu2.redhat.com [10.10.120.232]) by smtp.corp.redhat.com (Postfix) with ESMTP id 60F1F20292A8; Mon, 4 Jun 2018 15:34:56 +0000 (UTC) To: Ard Biesheuvel Cc: "edk2-devel@lists.01.org" , Leif Lindholm References: <20180604145028.437-1-ard.biesheuvel@linaro.org> From: Laszlo Ersek Message-ID: <171d5a52-57d9-9074-d30f-3a47bce77935@redhat.com> Date: Mon, 4 Jun 2018 17:34:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Mon, 04 Jun 2018 15:34:57 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Mon, 04 Jun 2018 15:34:57 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: [PATCH] ArmVirtPkg/ArmVirtQemu ARM: work around KVM limitations in LTO build X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 15:34:58 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 06/04/18 17:30, Ard Biesheuvel wrote: > On 4 June 2018 at 17:18, Laszlo Ersek 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 >>> --- >>> 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] >>> >>> NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf >>> } >>> + >>> +[Components.ARM] >>> + MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf { >>> + >>> + // >>> + // 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 . >> >> - 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. Can you please work some of the above answers (as you see fit) into the commit message, when you push the patch? Reviewed-by: Laszlo Ersek Thanks! Laszlo >> In general, I'm fine with the patch. According to [1] [2], this appears >> to be the right syntax for the goal. >> > > Thanks, >