Received: by 10.223.176.5 with SMTP id f5csp931776wra; Fri, 2 Feb 2018 08:25:53 -0800 (PST) X-Google-Smtp-Source: AH8x225t0EJ4mO/fZlI9ZPd/jZ80P1lDqUmQY3Ae+CMFs1A1i2m2lieIBwP4AoC6ouQvt2Yj9/Ul X-Received: by 10.98.156.71 with SMTP id f68mr41063695pfe.29.1517588753383; Fri, 02 Feb 2018 08:25:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517588753; cv=none; d=google.com; s=arc-20160816; b=uVRzS8MFVYiuE3R5vRjk8HNBOT5bNq93FAnWF5CdW209OnXhXgwz/ObCf5Wcfr6G+z 4Mh0J0WegGYF6Q8WBGKf+77WeSgblBJsyPy4NaKhb/qW/FBSHDMUURZrO4gagYCBrCEN bzUzhvuu9hSL78gxrVSFaor+9giD798zhp4DzrClQpXf7bHmawhp3BcSCBF32xnisym0 8vXkm/HAVwNhMWMC8CsOpuB9NEAChleUt+3KWV+j1EybkMw1fOJWjj3ostD+0wuxbMTA tbVkJ/HAOEQiLK7ix8ZGOI/MfwNBXENCey6KlOmY2NoejoXJ79SwddP+Tym4JT59OJC2 VdGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:from:subject:arc-authentication-results; bh=ThWjFzffiYX9qoJbS1PGNWUuj2ionyQb6mxFu7+bOKo=; b=IArzkpItie3Qdan3ZhxFbDva1f6ce/MTyPkTz7ODsWYwDe+IH9s7IEIxX19X4TdekS Ub3APoLm0iGUlRvYZozvwEhrCmtCb3bPcxC2auYU+fa0rMu1YduE5J/9KA0zeAqNsB0+ pKAmWHa61HqFn1pn+oAZ23/4PlDV/b+JP0QlBNihBv+JZM3A+cr/tw6je28OUE0uW5nV cPmuB7AD7n3nuz8tD+CGBnaT4mmiucJnMamYaqwymM9kOvwMNcsbs1MtmTyETzHXcWEj WJPemRv4Y3f81OYtbuWbs2L+KFx5diWzCcH03uxYMNn4rpo6icy7O3fkZUeNV06CQsm3 4Y1Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e32-v6si2047672plb.34.2018.02.02.08.25.37; Fri, 02 Feb 2018 08:25:53 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752352AbeBBQX5 (ORCPT + 99 others); Fri, 2 Feb 2018 11:23:57 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:33124 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751716AbeBBQXw (ORCPT ); Fri, 2 Feb 2018 11:23:52 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 385BC80D; Fri, 2 Feb 2018 08:23:52 -0800 (PST) Received: from [10.1.210.88] (e110467-lin.cambridge.arm.com [10.1.210.88]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 165E93F24D; Fri, 2 Feb 2018 08:23:49 -0800 (PST) Subject: Re: [PATCH 1/2] ARM: kvm: fix building with gcc-8 From: Robin Murphy To: Arnd Bergmann , Christoffer Dall , Marc Zyngier , Russell King Cc: Andi Kleen , Julien Thierry , Nicolas Pitre , linux-kernel@vger.kernel.org, stable@vger.kernel.org, Richard Earnshaw , Tamar Christina , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org References: <20180202150756.420422-1-arnd@arndb.de> <2cff070a-357d-c5f5-9ec6-036d93112ce4@arm.com> Message-ID: Date: Fri, 2 Feb 2018 16:23:48 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <2cff070a-357d-c5f5-9ec6-036d93112ce4@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/02/18 15:55, Robin Murphy wrote: > On 02/02/18 15:07, Arnd Bergmann wrote: >> In banked-sr.c, we use a top-level '__asm__(".arch_extension virt")' >> statement to allow compilation of a multi-CPU kernel for ARMv6 >> and older ARMv7-A that don't normally support access to the banked >> registers. >> >> This is considered to be a programming error by the gcc developers >> and will no longer work in gcc-8, where we now get a build error: >> >> /tmp/cc4Qy7GR.s:34: Error: Banked registers are not available with >> this architecture. -- `mrs r3,SP_usr' >> /tmp/cc4Qy7GR.s:41: Error: Banked registers are not available with >> this architecture. -- `mrs r3,ELR_hyp' >> /tmp/cc4Qy7GR.s:55: Error: Banked registers are not available with >> this architecture. -- `mrs r3,SP_svc' >> /tmp/cc4Qy7GR.s:62: Error: Banked registers are not available with >> this architecture. -- `mrs r3,LR_svc' >> /tmp/cc4Qy7GR.s:69: Error: Banked registers are not available with >> this architecture. -- `mrs r3,SPSR_svc' >> /tmp/cc4Qy7GR.s:76: Error: Banked registers are not available with >> this architecture. -- `mrs r3,SP_abt' >> >> Passign the '-march-armv7ve' flag to gcc works, and is ok here, because >> we know the functions won't ever be called on pre-ARMv7VE machines. >> Unfortunately, older compiler versions (4.8 and earlier) do not >> understand >> that flag, so we still need to keep the asm around. >> >> Backporting to stable kernels (4.6+) is needed to allow those to be built >> with future compilers as well. > > Is "-Wa,arch=armv7-a+virt" (as we appear to do for a couple of files > already) viable as a possibly cleaner alternative, or is GCC itself now > policing the contents of inline asms? In fact, looking at the binutils history, any version capable of assembling this file should understand that (modulo my typo), so hopefully it ought to be feasible to replace these global asms with assembler flags entirely. Robin. >> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84129 >> Fixes: 33280b4cd1dc ("ARM: KVM: Add banked registers save/restore") >> Cc: stable@vger.kernel.org >> Signed-off-by: Arnd Bergmann >> --- >>   arch/arm/kvm/hyp/Makefile    | 5 +++++ >>   arch/arm/kvm/hyp/banked-sr.c | 4 ++++ >>   2 files changed, 9 insertions(+) >> >> diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile >> index 5638ce0c9524..63d6b404d88e 100644 >> --- a/arch/arm/kvm/hyp/Makefile >> +++ b/arch/arm/kvm/hyp/Makefile >> @@ -7,6 +7,8 @@ ccflags-y += -fno-stack-protector >> -DDISABLE_BRANCH_PROFILING >>   KVM=../../../../virt/kvm >> +CFLAGS_ARMV7VE           :=$(call cc-option, -march=armv7ve) >> + >>   obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v2-sr.o >>   obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v3-sr.o >>   obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/timer-sr.o >> @@ -15,7 +17,10 @@ obj-$(CONFIG_KVM_ARM_HOST) += tlb.o >>   obj-$(CONFIG_KVM_ARM_HOST) += cp15-sr.o >>   obj-$(CONFIG_KVM_ARM_HOST) += vfp.o >>   obj-$(CONFIG_KVM_ARM_HOST) += banked-sr.o >> +CFLAGS_banked-sr.o       += $(CFLAGS_ARMV7VE) >> + >>   obj-$(CONFIG_KVM_ARM_HOST) += entry.o >>   obj-$(CONFIG_KVM_ARM_HOST) += hyp-entry.o >>   obj-$(CONFIG_KVM_ARM_HOST) += switch.o >> +CFLAGS_switch.o           += $(CFLAGS_ARMV7VE) >>   obj-$(CONFIG_KVM_ARM_HOST) += s2-setup.o >> diff --git a/arch/arm/kvm/hyp/banked-sr.c b/arch/arm/kvm/hyp/banked-sr.c >> index 111bda8cdebd..be4b8b0a40ad 100644 >> --- a/arch/arm/kvm/hyp/banked-sr.c >> +++ b/arch/arm/kvm/hyp/banked-sr.c >> @@ -20,6 +20,10 @@ >>   #include >> +/* >> + * gcc before 4.9 doesn't understand -march=armv7ve, so we have to >> + * trick the assembler. >> + */ >>   __asm__(".arch_extension     virt"); > > Would it be worth wrapping this in a preprocessor check for compilers > that won't understand the command-line flag? I believe LLVM tends to > choke on these global asm statements entirely, so minimising exposure > might be a good thing to do in general. > > Robin. > >>   void __hyp_text __banked_save_state(struct kvm_cpu_context *ctxt) >> > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel