From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c06::241; helo=mail-io0-x241.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5716F203B8CE6 for ; Mon, 4 Jun 2018 08:30:30 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id g22-v6so10379387iob.7 for ; Mon, 04 Jun 2018 08:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KFjRnFo/7qnUOUPA5yaFjhXedmaumv7dqtm2R0ZKyWI=; b=cLzR+MQI5Qw7UCyPXK+n8mq0V5ABW1WEEf+Rj/tE1pxv7d/OwqDEQSHxGU734utkmK T06XGW+NRCfczBpiDR2Iz12kNmwToItz3ku/yikcoLB889RmfKiG4JWZnnVYG5CvU/lY NRyTAssFysgotskjBdF//Gv2lkXuUmE9qqk0k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KFjRnFo/7qnUOUPA5yaFjhXedmaumv7dqtm2R0ZKyWI=; b=Lc9WvqIapyKzMLdBjviwmJg2LWMYLMeaDq+098RkYZXBxd+FJyqdt9WbSNK4tFb1yN iJtGoPNSUp7nuD9ZmpnQ+albAKXqrH1eqYCzw/JF0T3m+tbeXK9sjRBQo/zD4eN/DDE0 VLY3gjNQm2mrDMERxV38pblJq34ts9nOQPVJHWByvHguM1XBiaYsSTPrCE+BlUQDTEi8 c+23WA03f03AMTmvDak6CJwdusxE0uRpDfWbSM5H4w1/WuyVYMO5BGB6Ckf5YTe3GA14 3QGfR495mLQC1A6NYjWOMbr3ntTFWpBx0tt1K48PKhm2SpNSQUiCt9977hkXM4jBDC5V qIrg== X-Gm-Message-State: APt69E0cQ363OHN3TkNUQCMe/XAxDpihKkr80/dwP/Q2dGv34AHar3mi NBG3oGYbb2TAnb+ugZPBcH6K8rwvU/xuujEZpFZ9nw== X-Google-Smtp-Source: ADUXVKL6hQHAl6jv+gsMFmaMs2D5SSwa1MWVI+XOWot18qk1aFFE1Fr70GIdv38bjCfH3ggWcM387es8raWWZ0ZEN/4= X-Received: by 2002:a6b:dd0b:: with SMTP id f11-v6mr5092960ioc.173.1528126228042; Mon, 04 Jun 2018 08:30:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bb86:0:0:0:0:0 with HTTP; Mon, 4 Jun 2018 08:30:27 -0700 (PDT) In-Reply-To: References: <20180604145028.437-1-ard.biesheuvel@linaro.org> From: Ard Biesheuvel Date: Mon, 4 Jun 2018 17:30:27 +0200 Message-ID: To: Laszlo Ersek Cc: "edk2-devel@lists.01.org" , Leif Lindholm 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:30:30 -0000 Content-Type: text/plain; charset="UTF-8" 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. > In general, I'm fine with the patch. According to [1] [2], this appears > to be the right syntax for the goal. > Thanks,