From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Zyngier Subject: Re: [PATCH 2/3] arm64: KVM: Allow for direct call of HYP functions when using VHE Date: Wed, 9 Jan 2019 14:45:29 +0000 Message-ID: References: <20190109135435.178664-1-marc.zyngier@arm.com> <20190109135435.178664-3-marc.zyngier@arm.com> <20190109142407.GH56789@e119886-lin.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org To: Andrew Murray Return-path: In-Reply-To: <20190109142407.GH56789@e119886-lin.cambridge.arm.com> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org List-Id: kvm.vger.kernel.org Hi Andrew, On 09/01/2019 14:24, Andrew Murray wrote: > On Wed, Jan 09, 2019 at 01:54:34PM +0000, Marc Zyngier wrote: >> When running VHE, there is no need to jump via some stub to perform >> a "HYP" function call, as there is a single address space. >> >> Let's thus change kvm_call_hyp() and co to perform a direct call >> in this case. Although this results in a bit of code expansion, >> it allows the compiler to check for type compatibility, something >> that we are missing so far. >> >> Signed-off-by: Marc Zyngier >> --- >> arch/arm64/include/asm/kvm_host.h | 32 +++++++++++++++++++++++++++++-- >> 1 file changed, 30 insertions(+), 2 deletions(-) >> >> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h >> index e54cb7c88a4e..df32edbadd69 100644 >> --- a/arch/arm64/include/asm/kvm_host.h >> +++ b/arch/arm64/include/asm/kvm_host.h >> @@ -370,8 +370,36 @@ void kvm_arm_halt_guest(struct kvm *kvm); >> void kvm_arm_resume_guest(struct kvm *kvm); >> >> u64 __kvm_call_hyp(void *hypfn, ...); >> -#define kvm_call_hyp(f, ...) __kvm_call_hyp(kvm_ksym_ref(f), ##__VA_ARGS__) >> -#define kvm_call_hyp_ret(f, ...) kvm_call_hyp(f, ##__VA_ARGS__) >> + >> +/* >> + * The couple of isb() below are there to guarantee the same behaviour >> + * on VHE as on !VHE, where the eret to EL1 acts as a context >> + * synchronization event. >> + */ >> +#define kvm_call_hyp(f, ...) \ >> + do { \ >> + if (cpus_have_const_cap(ARM64_HAS_VIRT_HOST_EXTN)) { \ >> + f(__VA_ARGS__); \ >> + isb(); \ >> + } else { \ >> + __kvm_call_hyp(kvm_ksym_ref(f), ##__VA_ARGS__); \ >> + } \ >> + } while(0) >> + >> +#define kvm_call_hyp_ret(f, ...) \ >> + ({ \ >> + u64 ret; \ >> + \ >> + if (cpus_have_const_cap(ARM64_HAS_VIRT_HOST_EXTN)) { \ >> + ret = f(__VA_ARGS__); \ > > __kvm_get_mdcr_el2 and __kvm_vcpu_run_nvhe don't return u64 type, they > return a smaller type. I guess any issues would be picked up when compiling, > but should the name of the macro be clearer as to the assumptions it makes? > Or perhaps take an argument which is the type of ret? kvm_call_hyp has always returned a u64, so no semantic has changed here. Otherwise, your suggestion of specifying a return type is interesting, but it also gives the programmer another chance to shoot itself in the foot by not providing the return type corresponding to the function that is called. Unless we can extract the return type by pure magic, I'm not sure we gain much. Thanks, M. -- Jazz is not dead. It just smells funny... From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 820FEC43444 for ; Wed, 9 Jan 2019 14:45:36 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 51E62206BA for ; Wed, 9 Jan 2019 14:45:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Nd56kIyS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 51E62206BA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ueRZM9mvWFOCy5cx4b2RuTs956JbpFDvvzHWLspGXgM=; b=Nd56kIySfmW4a6 bjWjEnBDUzbQbfBIBmKVU2UfBNE9zYd5ITST1hixPyhadeJUXLjpLzV0kJSjRdh9LGykTW9+7xTTf phzKG9X6wtVzhYRmYmwuEvSeG1aKuJ69j5pLjkjxfwMAzkK3RTdbLeemP1Yq1CDxBfZGKvfjXv/Np /WI6DYr31hBBv/UlGLrNBkFiTi2H6eKA56pC9K/0tRgG2XTE1tP2elpcL2Qo3ZYDc+C0X+AAiQXa5 nscDo1/dApDhsy7L5s/CX/+hVvgDqLWLzt820sDtEmDmzk4KgzlJoo+Tkft6PVb72bIaYkMwrZusq nTMGfSrPWs0nqJM6M/YQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1ghF6s-00037g-I1; Wed, 09 Jan 2019 14:45:34 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1ghF6q-00036y-8J for linux-arm-kernel@lists.infradead.org; Wed, 09 Jan 2019 14:45:33 +0000 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 BE51D80D; Wed, 9 Jan 2019 06:45:31 -0800 (PST) Received: from [10.1.196.62] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id ED9153F6CF; Wed, 9 Jan 2019 06:45:30 -0800 (PST) Subject: Re: [PATCH 2/3] arm64: KVM: Allow for direct call of HYP functions when using VHE To: Andrew Murray References: <20190109135435.178664-1-marc.zyngier@arm.com> <20190109135435.178664-3-marc.zyngier@arm.com> <20190109142407.GH56789@e119886-lin.cambridge.arm.com> From: Marc Zyngier Openpgp: preference=signencrypt Autocrypt: addr=marc.zyngier@arm.com; prefer-encrypt=mutual; keydata= mQINBE6Jf0UBEADLCxpix34Ch3kQKA9SNlVQroj9aHAEzzl0+V8jrvT9a9GkK+FjBOIQz4KE g+3p+lqgJH4NfwPm9H5I5e3wa+Scz9wAqWLTT772Rqb6hf6kx0kKd0P2jGv79qXSmwru28vJ t9NNsmIhEYwS5eTfCbsZZDCnR31J6qxozsDHpCGLHlYym/VbC199Uq/pN5gH+5JHZyhyZiNW ozUCjMqC4eNW42nYVKZQfbj/k4W9xFfudFaFEhAf/Vb1r6F05eBP1uopuzNkAN7vqS8XcgQH qXI357YC4ToCbmqLue4HK9+2mtf7MTdHZYGZ939OfTlOGuxFW+bhtPQzsHiW7eNe0ew0+LaL 3wdNzT5abPBscqXWVGsZWCAzBmrZato+Pd2bSCDPLInZV0j+rjt7MWiSxEAEowue3IcZA++7 ifTDIscQdpeKT8hcL+9eHLgoSDH62SlubO/y8bB1hV8JjLW/jQpLnae0oz25h39ij4ijcp8N t5slf5DNRi1NLz5+iaaLg4gaM3ywVK2VEKdBTg+JTg3dfrb3DH7ctTQquyKun9IVY8AsxMc6 lxl4HxrpLX7HgF10685GG5fFla7R1RUnW5svgQhz6YVU33yJjk5lIIrrxKI/wLlhn066mtu1 DoD9TEAjwOmpa6ofV6rHeBPehUwMZEsLqlKfLsl0PpsJwov8TQARAQABtCNNYXJjIFp5bmdp ZXIgPG1hcmMuenluZ2llckBhcm0uY29tPokCOwQTAQIAJQIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AFAk6NvYYCGQEACgkQI9DQutE9ekObww/+NcUATWXOcnoPflpYG43GZ0XjQLng LQFjBZL+CJV5+1XMDfz4ATH37cR+8gMO1UwmWPv5tOMKLHhw6uLxGG4upPAm0qxjRA/SE3LC 22kBjWiSMrkQgv5FDcwdhAcj8A+gKgcXBeyXsGBXLjo5UQOGvPTQXcqNXB9A3ZZN9vS6QUYN TXFjnUnzCJd+PVI/4jORz9EUVw1q/+kZgmA8/GhfPH3xNetTGLyJCJcQ86acom2liLZZX4+1 6Hda2x3hxpoQo7pTu+XA2YC4XyUstNDYIsE4F4NVHGi88a3N8yWE+Z7cBI2HjGvpfNxZnmKX 6bws6RQ4LHDPhy0yzWFowJXGTqM/e79c1UeqOVxKGFF3VhJJu1nMlh+5hnW4glXOoy/WmDEM UMbl9KbJUfo+GgIQGMp8mwgW0vK4HrSmevlDeMcrLdfbbFbcZLNeFFBn6KqxFZaTd+LpylIH bOPN6fy1Dxf7UZscogYw5Pt0JscgpciuO3DAZo3eXz6ffj2NrWchnbj+SpPBiH4srfFmHY+Y LBemIIOmSqIsjoSRjNEZeEObkshDVG5NncJzbAQY+V3Q3yo9og/8ZiaulVWDbcpKyUpzt7pv cdnY3baDE8ate/cymFP5jGJK++QCeA6u6JzBp7HnKbngqWa6g8qDSjPXBPCLmmRWbc5j0lvA 6ilrF8m5Ag0ETol/RQEQAM/2pdLYCWmf3rtIiP8Wj5NwyjSL6/UrChXtoX9wlY8a4h3EX6E3 64snIJVMLbyr4bwdmPKULlny7T/R8dx/mCOWu/DztrVNQiXWOTKJnd/2iQblBT+W5W8ep/nS w3qUIckKwKdplQtzSKeE+PJ+GMS+DoNDDkcrVjUnsoCEr0aK3cO6g5hLGu8IBbC1CJYSpple VVb/sADnWF3SfUvJ/l4K8Uk4B4+X90KpA7U9MhvDTCy5mJGaTsFqDLpnqp/yqaT2P7kyMG2E w+eqtVIqwwweZA0S+tuqput5xdNAcsj2PugVx9tlw/LJo39nh8NrMxAhv5aQ+JJ2I8UTiHLX QvoC0Yc/jZX/JRB5r4x4IhK34Mv5TiH/gFfZbwxd287Y1jOaD9lhnke1SX5MXF7eCT3cgyB+ hgSu42w+2xYl3+rzIhQqxXhaP232t/b3ilJO00ZZ19d4KICGcakeiL6ZBtD8TrtkRiewI3v0 o8rUBWtjcDRgg3tWx/PcJvZnw1twbmRdaNvsvnlapD2Y9Js3woRLIjSAGOijwzFXSJyC2HU1 AAuR9uo4/QkeIrQVHIxP7TJZdJ9sGEWdeGPzzPlKLHwIX2HzfbdtPejPSXm5LJ026qdtJHgz BAb3NygZG6BH6EC1NPDQ6O53EXorXS1tsSAgp5ZDSFEBklpRVT3E0NrDABEBAAGJAh8EGAEC AAkFAk6Jf0UCGwwACgkQI9DQutE9ekMLBQ//U+Mt9DtFpzMCIHFPE9nNlsCm75j22lNiw6mX mx3cUA3pl+uRGQr/zQC5inQNtjFUmwGkHqrAw+SmG5gsgnM4pSdYvraWaCWOZCQCx1lpaCOl MotrNcwMJTJLQGc4BjJyOeSH59HQDitKfKMu/yjRhzT8CXhys6R0kYMrEN0tbe1cFOJkxSbV 0GgRTDF4PKyLT+RncoKxQe8lGxuk5614aRpBQa0LPafkirwqkUtxsPnarkPUEfkBlnIhAR8L kmneYLu0AvbWjfJCUH7qfpyS/FRrQCoBq9QIEcf2v1f0AIpA27f9KCEv5MZSHXGCdNcbjKw1 39YxYZhmXaHFKDSZIC29YhQJeXWlfDEDq6nIhvurZy3mSh2OMQgaIoFexPCsBBOclH8QUtMk a3jW/qYyrV+qUq9Wf3SKPrXf7B3xB332jFCETbyZQXqmowV+2b3rJFRWn5hK5B+xwvuxKyGq qDOGjof2dKl2zBIxbFgOclV7wqCVkhxSJi/QaOj2zBqSNPXga5DWtX3ekRnJLa1+ijXxmdjz hApihi08gwvP5G9fNGKQyRETePEtEAWt0b7dOqMzYBYGRVr7uS4uT6WP7fzOwAJC4lU7ZYWZ yVshCa0IvTtp1085RtT3qhh9mobkcZ+7cQOY+Tx2RGXS9WeOh2jZjdoWUv6CevXNQyOUXMM= Organization: ARM Ltd Message-ID: Date: Wed, 9 Jan 2019 14:45:29 +0000 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <20190109142407.GH56789@e119886-lin.cambridge.arm.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190109_064532_305771_579D686D X-CRM114-Status: GOOD ( 19.80 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Andrew, On 09/01/2019 14:24, Andrew Murray wrote: > On Wed, Jan 09, 2019 at 01:54:34PM +0000, Marc Zyngier wrote: >> When running VHE, there is no need to jump via some stub to perform >> a "HYP" function call, as there is a single address space. >> >> Let's thus change kvm_call_hyp() and co to perform a direct call >> in this case. Although this results in a bit of code expansion, >> it allows the compiler to check for type compatibility, something >> that we are missing so far. >> >> Signed-off-by: Marc Zyngier >> --- >> arch/arm64/include/asm/kvm_host.h | 32 +++++++++++++++++++++++++++++-- >> 1 file changed, 30 insertions(+), 2 deletions(-) >> >> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h >> index e54cb7c88a4e..df32edbadd69 100644 >> --- a/arch/arm64/include/asm/kvm_host.h >> +++ b/arch/arm64/include/asm/kvm_host.h >> @@ -370,8 +370,36 @@ void kvm_arm_halt_guest(struct kvm *kvm); >> void kvm_arm_resume_guest(struct kvm *kvm); >> >> u64 __kvm_call_hyp(void *hypfn, ...); >> -#define kvm_call_hyp(f, ...) __kvm_call_hyp(kvm_ksym_ref(f), ##__VA_ARGS__) >> -#define kvm_call_hyp_ret(f, ...) kvm_call_hyp(f, ##__VA_ARGS__) >> + >> +/* >> + * The couple of isb() below are there to guarantee the same behaviour >> + * on VHE as on !VHE, where the eret to EL1 acts as a context >> + * synchronization event. >> + */ >> +#define kvm_call_hyp(f, ...) \ >> + do { \ >> + if (cpus_have_const_cap(ARM64_HAS_VIRT_HOST_EXTN)) { \ >> + f(__VA_ARGS__); \ >> + isb(); \ >> + } else { \ >> + __kvm_call_hyp(kvm_ksym_ref(f), ##__VA_ARGS__); \ >> + } \ >> + } while(0) >> + >> +#define kvm_call_hyp_ret(f, ...) \ >> + ({ \ >> + u64 ret; \ >> + \ >> + if (cpus_have_const_cap(ARM64_HAS_VIRT_HOST_EXTN)) { \ >> + ret = f(__VA_ARGS__); \ > > __kvm_get_mdcr_el2 and __kvm_vcpu_run_nvhe don't return u64 type, they > return a smaller type. I guess any issues would be picked up when compiling, > but should the name of the macro be clearer as to the assumptions it makes? > Or perhaps take an argument which is the type of ret? kvm_call_hyp has always returned a u64, so no semantic has changed here. Otherwise, your suggestion of specifying a return type is interesting, but it also gives the programmer another chance to shoot itself in the foot by not providing the return type corresponding to the function that is called. Unless we can extract the return type by pure magic, I'm not sure we gain much. Thanks, M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel