Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp925829rwn; Thu, 8 Sep 2022 10:36:39 -0700 (PDT) X-Google-Smtp-Source: AA6agR7IzTN5KK+PhBLGpTcgEBTqFxNZpDABD5uaSVt8dlYVtucQEclMyVS9FhtDKfLDWZ3pvUI/ X-Received: by 2002:a63:4750:0:b0:42b:609d:538a with SMTP id w16-20020a634750000000b0042b609d538amr8792883pgk.217.1662658599523; Thu, 08 Sep 2022 10:36:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662658599; cv=none; d=google.com; s=arc-20160816; b=jFegNBB0wTPshIT8GlJa4ER41sIiam+NZLiK3Pu3CVGsvvylHT2cTd+rS3htmWIc0N 1Dz3LZ4HNzVTrEdZR1by3PSJBtsIkh8BjntA0iEqS0kZloyGM7iCfUV5AOzT9Z74+S2s L7U6kM1d+1YkjxXYDhsA7+D4PsF9AcWfYoZkCza5r6OA8bMK94JsOzEuEz+p86YPhNIW njMqFrc8PxSkFDRS7gtLZtZwUZZzKXUP1tq3VBoWktgdkTDlgjNCHo7BTu9sj0jzwCll cZrN+Z+ll5YyGH67Y+unFSDsHAllasFwvVLgnqta/5JYM4slrfrABSNbBBD7bWsQbqey 0XfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=0RNd0xzxjuuqcXZ1VJEa1kbSJZUe0y9yps+WlJN0nCg=; b=JMEj43sJOv8YMs8vQymobi7jQK1/ebO8uSj7nYanmMink0ioI7Z9z8hZLy90iqa0OH HbKk+mdOBws54ykYk438bK/MW7b64mxc/XOn+vVXS8Yy3oOTWoLYDlLW/QXVgKOBqvrT VidMNb08R9mYDmGjtwgBlVUsB15ghQCh9fubJzYt9cOoW+AoNxH0sS/sYVpJvOaMiKSP PYf5bX1s2r/VVxQMKoT0DOdUPaHv54HKvftG6dOjBsHi74VrekTrf7RyDbRe5MJ5UB0c afeS9VBFG9xZxrHnHXVwAOf9gcPYMuuxcLTzQIeG5baYi7LIJj5FhliJGpe0bcm6GA4a 2c4w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=AStEFPv3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qi10-20020a17090b274a00b00200b135df56si2753031pjb.147.2022.09.08.10.36.26; Thu, 08 Sep 2022 10:36:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=AStEFPv3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231423AbiIHRX5 (ORCPT + 99 others); Thu, 8 Sep 2022 13:23:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51748 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231172AbiIHRXx (ORCPT ); Thu, 8 Sep 2022 13:23:53 -0400 Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F1E28F02A0 for ; Thu, 8 Sep 2022 10:23:51 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id 9so15353389plj.11 for ; Thu, 08 Sep 2022 10:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date; bh=0RNd0xzxjuuqcXZ1VJEa1kbSJZUe0y9yps+WlJN0nCg=; b=AStEFPv3MsxwGRwF6reOs3E+AdAfGuwDLh3caMiejk1AmBHiCn4VVhxqlp/ipyPW+d EPhoNhRoA4JdlYbMqQ0UGdAgtGVg2UsQKmzZVzpjN+lTIP0NlfHdQ2yGQ9DrAMMZ30SX uVZn2PHOdKJH++hE5CJ9+N3tFc2EL55mtTCFyhMMJ/ZJXJxHJJq1slFtGD0R6hQJv/75 G9q2wrKRrF0ZC4YJlHGPxq7hI2S05U46l/XA4fssLZKW3eieAVQXjbGZ8At1MpgD8cAn d6f8yXUmqBASFtgYVVdQbPKpy6PUJjv4u0x36I0pllO7F8dpz3qXfLyOqsnYn9L52vcV SaPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date; bh=0RNd0xzxjuuqcXZ1VJEa1kbSJZUe0y9yps+WlJN0nCg=; b=1Nr4DPJG6qOCDLn0mJkqE0QzlNvjJGf2ZW70l2W112npKhKFx0nX2eP5GIxSK+qZMd eXPx37KY0gDowNu2vl2daBkiheTdkdHqQ0frjP8NBSZxw2jEvLfdxj6khHXZxe1NbkDb Q1sk0TBF9u5BR9CBdNKHxI/P2e1tPHgaX/cEZuJ7mJzKa3wQudwMdCyJNFhpVi0xrPZR 8xqFBne04f4CVVMXw0ukSH7ZY0AxRMavA62iT1+FBxdRV1dIPNOCWcutXaZ5MHVPW4nk wZtB6/M90OUjHx8WqOei0Zl8qxIDMSJRR00CLegOGg7Xv41+QCo7/6YHwrVdT7AeXPiE XAkA== X-Gm-Message-State: ACgBeo3aNjULMPTvdp0HlttzLWnP5dU62Q7A4TpTuK3jaC/aMUsl6wDt shk6QjX4rwXINp8Qf+yvAKUhAA== X-Received: by 2002:a17:902:be01:b0:176:8bc3:b379 with SMTP id r1-20020a170902be0100b001768bc3b379mr10154520pls.109.1662657831302; Thu, 08 Sep 2022 10:23:51 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id d6-20020a170902654600b00172dc6e1916sm9901814pln.220.2022.09.08.10.23.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Sep 2022 10:23:50 -0700 (PDT) Date: Thu, 8 Sep 2022 17:23:47 +0000 From: Sean Christopherson To: Uros Bizjak Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Bonzini Subject: Re: [PATCH] KVM/VMX: Do not declare vmread_error asmlinkage Message-ID: References: <20220817144045.3206-1-ubizjak@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 01, 2022, Uros Bizjak wrote: > On Thu, Sep 1, 2022 at 5:40 PM Sean Christopherson wrote: > > > > On Wed, Aug 17, 2022, Uros Bizjak wrote: > > > There is no need to declare vmread_error asmlinkage, its arguments > > > can be passed via registers for both, 32-bit and 64-bit targets. > > > Function argument registers are considered call-clobbered registers, > > > they are saved in the trampoline just before the function call and > > > restored afterwards. > > > > > > Note that asmlinkage and __attribute__((regparm(0))) have no effect > > > on 64-bit targets. The trampoline is called from the assembler glue > > > code that implements its own stack-passing function calling convention, > > > so the attribute on the trampoline declaration does not change anything > > > for 64-bit as well as 32-bit targets. We can declare it asmlinkage for > > > documentation purposes. > > > > ... > > > > > diff --git a/arch/x86/kvm/vmx/vmx_ops.h b/arch/x86/kvm/vmx/vmx_ops.h > > > index 5cfc49ddb1b4..550a89394d9f 100644 > > > --- a/arch/x86/kvm/vmx/vmx_ops.h > > > +++ b/arch/x86/kvm/vmx/vmx_ops.h > > > @@ -10,9 +10,9 @@ > > > #include "vmcs.h" > > > #include "../x86.h" > > > > > > -asmlinkage void vmread_error(unsigned long field, bool fault); > > > -__attribute__((regparm(0))) void vmread_error_trampoline(unsigned long field, > > > - bool fault); > > > +void vmread_error(unsigned long field, bool fault); > > > +asmlinkage void vmread_error_trampoline(unsigned long field, > > > + bool fault); > > > void vmwrite_error(unsigned long field, unsigned long value); > > > void vmclear_error(struct vmcs *vmcs, u64 phys_addr); > > > void vmptrld_error(struct vmcs *vmcs, u64 phys_addr); > > > > If it's ok with you, I'll split this into two patches. One to drop asmlinkage > > from vmread_error(), and one to convert the open coded regparm to asmlinkage. > > Sure, please go ahead. On second thought, even though "__attribute__((regparm(0)))" doesn't actually do anything for 64-bit targets, I'd prefer to keep the open coded weirdness _because_ the whole thing is open coded weirdness. The attribute isn't strictly necessary for 32-bit targets either since the CALL is emitted from inline assembly. I now remember that I added the explicit regparm(0) to try and document that vmread_error_trampoline() _always_ passes params on the stack, even for 64-bit targets, i.e. even if "asmlinkage" is a nop. Alternatively, given that the trampoline exists purely to support inline asm, i.e. should never be called from C code in any circumstance, what about turning the function declaration into an opaque symbol and then writing a proper comment. That way, attempting to invoke vmread_error_trampoline() from C yields: arch/x86/kernel/../kvm/vmx/vmx_ops.h: In function ‘__vmcs_readl’: arch/x86/kernel/../kvm/vmx/vmx_ops.h:113:2: error: called object ‘vmread_error_trampoline’ is not a function or function pointer 113 | vmread_error_trampoline(field, false); | ^~~~~~~~~~~~~~~~~~~~~~~ arch/x86/kernel/../kvm/vmx/vmx_ops.h:33:22: note: declared here 33 | extern unsigned long vmread_error_trampoline; | ^~~~~~~~~~~~~~~~~~~~~~~ --- From: Sean Christopherson Date: Thu, 8 Sep 2022 10:17:40 -0700 Subject: [PATCH] KVM: VMX: Make vmread_error_trampoline() uncallable from C code Declare vmread_error_trampoline() as an opaque symbol so that it cannot be called from C code, at least not without some serious fudging. The trampoline always passes parameters on the stack so that the inline VMREAD sequence doesn't need to clobber registers. regparm(0) was originally added to document the stack behavior, but it ended up being confusing because regparm(0) is a nop for 64-bit targets. Opportunustically wrap the trampoline and its declaration in #ifdeffery to make it even harder to invoke incorrectly, to document why it exists, and so that it's not left behind if/when CONFIG_CC_HAS_ASM_GOTO_OUTPUT is true for all supported toolchains. No functional change intended. Signed-off-by: Sean Christopherson --- arch/x86/kvm/vmx/vmenter.S | 2 ++ arch/x86/kvm/vmx/vmx_ops.h | 18 ++++++++++++++++-- 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/vmx/vmenter.S b/arch/x86/kvm/vmx/vmenter.S index 8477d8bdd69c..24c54577ac84 100644 --- a/arch/x86/kvm/vmx/vmenter.S +++ b/arch/x86/kvm/vmx/vmenter.S @@ -269,6 +269,7 @@ SYM_FUNC_END(__vmx_vcpu_run) .section .text, "ax" +#ifndef CONFIG_CC_HAS_ASM_GOTO_OUTPUT /** * vmread_error_trampoline - Trampoline from inline asm to vmread_error() * @field: VMCS field encoding that failed @@ -317,6 +318,7 @@ SYM_FUNC_START(vmread_error_trampoline) RET SYM_FUNC_END(vmread_error_trampoline) +#endif SYM_FUNC_START(vmx_do_interrupt_nmi_irqoff) /* diff --git a/arch/x86/kvm/vmx/vmx_ops.h b/arch/x86/kvm/vmx/vmx_ops.h index ec268df83ed6..7ea99e6b4908 100644 --- a/arch/x86/kvm/vmx/vmx_ops.h +++ b/arch/x86/kvm/vmx/vmx_ops.h @@ -11,14 +11,28 @@ #include "../x86.h" void vmread_error(unsigned long field, bool fault); -__attribute__((regparm(0))) void vmread_error_trampoline(unsigned long field, - bool fault); void vmwrite_error(unsigned long field, unsigned long value); void vmclear_error(struct vmcs *vmcs, u64 phys_addr); void vmptrld_error(struct vmcs *vmcs, u64 phys_addr); void invvpid_error(unsigned long ext, u16 vpid, gva_t gva); void invept_error(unsigned long ext, u64 eptp, gpa_t gpa); +#ifndef CONFIG_CC_HAS_ASM_GOTO_OUTPUT +/* + * The VMREAD error trampoline _always_ uses the stack to pass parameters, even + * for 64-bit targets. Preserving all registers allows the VMREAD inline asm + * blob to avoid clobbering GPRs, which in turn allows the compiler to better + * optimize sequences of VMREADs. + * + * Declare trampoline as an opaque label as it's not safe to call from C code; + * there is no way to tell the compiler to pass params on the stack for 64-bit + * targets. + * + * void vmread_error_trampoline(unsigned long field, bool fault); + */ +extern unsigned long vmread_error_trampoline; +#endif + static __always_inline void vmcs_check16(unsigned long field) { BUILD_BUG_ON_MSG(__builtin_constant_p(field) && ((field) & 0x6001) == 0x2000, base-commit: d2a22504d86e106c63236e4d6a085c2ac91bfa73 --