Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp975909pxb; Wed, 1 Sep 2021 14:13:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwEqXcHv4ZdKhRI/x8Pa+pMj9fsjcLY0zsUpf2b9IIX7ZRhjXAS6SGRSsat7r/9SdSuE84c X-Received: by 2002:a02:2a07:: with SMTP id w7mr1388490jaw.96.1630530803967; Wed, 01 Sep 2021 14:13:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630530803; cv=none; d=google.com; s=arc-20160816; b=x1kWT8JQ8d7LBqguYGpCM9Bei5zAIEkntrLhA2nHMfHBlSMkLP6ZFVahzAblVNA2Fb J0/M4UUpiwxSjO1myPkEcaRpW686qDhxqlFCY++ao2exD68A183TojW03us4pI8YVtz7 HzDV3F+TYtxZVPkl7M2RVaU7jyxKe+6b14znJhPzv8u8SYE6uZHqYiLdbuhKCdkzLRn1 A9iBHs4gLlXhomQoompIJ5mgtmIYmXaC7HrLFFowAJZfSFkgUoDKoclapd89IpYRx/Lp q8GA0QCs/SXWJWxzuZJI6PsLvcgxRd7VRLBQpt8KZEW8hko9HQYNA2IUDbZ9pGFkYBhV MFUQ== 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-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=egGMiPBBKlMbvE9KfJkUfu/tC90iKtmhmrZtESxeA28=; b=qOSv7xLGtxqTkOdf9niqQ0A2iNABUDxeAYt3Vz+W3IX0FKipnu9q4TMmSVv1EJSXxi 5vhP3oeqVUtfhVsIG0qjIJSp6Fikz+EKm4bKpiVxTsCNAbIW9NO/SCimqkn0NjraxVvs 5RcjbCVFNSjhy40iwczHTxrwcW+0KeiyvfQep6TXwf0iVyniG32qfF6o8PQII2AVgAnx cHRp/bMZl5Hmc/I7mluZFn+jmgYePC3yILsbEtFN4F9B4x9iX+kzYKHDe4Kxorq8Rd5b UPcsrX0FmMzP7RAqo1vUipLJX6LaisYW1HTUxoHJzNvzWTMk+L29fnDz+1xVNXti6eeN 4wlQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ncreY0Gm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m11si636268jaj.5.2021.09.01.14.13.12; Wed, 01 Sep 2021 14:13:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ncreY0Gm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S245458AbhIAVNN (ORCPT + 99 others); Wed, 1 Sep 2021 17:13:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39240 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245209AbhIAVNM (ORCPT ); Wed, 1 Sep 2021 17:13:12 -0400 Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7AA92C061764 for ; Wed, 1 Sep 2021 14:12:15 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id n18so771197pgm.12 for ; Wed, 01 Sep 2021 14:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=egGMiPBBKlMbvE9KfJkUfu/tC90iKtmhmrZtESxeA28=; b=ncreY0Gm4kTVQgl+kXCW0CKEReUCKnUK13+j8VNBk3y9UZw+yTehvdd/AY70Kv2rhM 1Cdw1qYid5Nd/nyvRZ5m48JFj44/RkoiiV9o82xeVWF4q3aE1f5qX22OSK40jCSy2BAY hc/66Mxogl+2uVO+FcHPtfoCXVMoNAEsiGlKdJd0gLmxQXO62S6JRtvPZfK5GfpQlnXg aY70KSzqfqfEMBfimNc6hBVUHSYO29XSZ65jwxHwc/4Ds6HliyWNgw1tZRPl/6geHSW+ AOVWvfND7s1JWPMF+7XKgIf8OXGQwS+QCvMfH0JB6TbPXDs7aZmymFSaZQBU0eH58nhp 2USg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=egGMiPBBKlMbvE9KfJkUfu/tC90iKtmhmrZtESxeA28=; b=WnfbFaJz4399XonIhvecK5up0hDHNdV/O3dliZPKLpQhftVdHk2ljYEVzNeyLviyjw 7iatq4mO38Vm/FainEq0xOgptvMonup4mG4zhah3ZyYLNLxkegv6d2oTCju0Th74z3qE ag1W/xdK8MDoRKKnGVlwlJEipl8ysYlaXm7UPqto3/FyOdBUAG3m0wAiOMPnQDVtK7tt fx8ay12qcU/r8dCTO9AsDSv3PuJbBGJYwEl6IIoPGe+HwK7TVsW0a3NEs9G7I77J8gsV /JHQN1mEPzif3v5GGy0o1eRES+fxbXkxwVnl83wRX/9tQabkBUmpuGJ6nqVYAzuWPMyU YXhQ== X-Gm-Message-State: AOAM531Ohd+9Cb9TS+encf1BDE/VSVg9L1R0i6NKLE9f1bMdRgCnnwtO IZcqlwhmRK9EYgr0SY/lPNJoBA== X-Received: by 2002:a05:6a00:15c4:b0:3eb:2447:97bd with SMTP id o4-20020a056a0015c400b003eb244797bdmr1343500pfu.4.1630530734724; Wed, 01 Sep 2021 14:12:14 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id y12sm550751pgl.65.2021.09.01.14.12.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Sep 2021 14:12:14 -0700 (PDT) Date: Wed, 1 Sep 2021 21:12:10 +0000 From: Sean Christopherson To: Joerg Roedel Cc: Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Brijesh Singh , Tom Lendacky , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, Joerg Roedel Subject: Re: [PATCH v2 1/4] KVM: SVM: Get rid of *ghcb_msr_bits() functions Message-ID: References: <20210722115245.16084-1-joro@8bytes.org> <20210722115245.16084-2-joro@8bytes.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210722115245.16084-2-joro@8bytes.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 22, 2021, Joerg Roedel wrote: > From: Joerg Roedel > > Replace the get function with macros and the set function with > hypercall specific setters. This will avoid preserving any previous > bits in the GHCB-MSR and improved code readability. > > Suggested-by: Sean Christopherson > Signed-off-by: Joerg Roedel > --- > arch/x86/include/asm/sev-common.h | 9 +++++++ > arch/x86/kvm/svm/sev.c | 41 +++++++++++-------------------- > 2 files changed, 24 insertions(+), 26 deletions(-) > > diff --git a/arch/x86/include/asm/sev-common.h b/arch/x86/include/asm/sev-common.h > index 2cef6c5a52c2..8540972cad04 100644 > --- a/arch/x86/include/asm/sev-common.h > +++ b/arch/x86/include/asm/sev-common.h > @@ -50,6 +50,10 @@ > (GHCB_MSR_CPUID_REQ | \ > (((unsigned long)reg & GHCB_MSR_CPUID_REG_MASK) << GHCB_MSR_CPUID_REG_POS) | \ > (((unsigned long)fn) << GHCB_MSR_CPUID_FUNC_POS)) > +#define GHCB_MSR_CPUID_FN(msr) \ > + (((msr) >> GHCB_MSR_CPUID_FUNC_POS) & GHCB_MSR_CPUID_FUNC_MASK) > +#define GHCB_MSR_CPUID_REG(msr) \ > + (((msr) >> GHCB_MSR_CPUID_REG_POS) & GHCB_MSR_CPUID_REG_MASK) > > /* AP Reset Hold */ > #define GHCB_MSR_AP_RESET_HOLD_REQ 0x006 > @@ -67,6 +71,11 @@ > #define GHCB_SEV_TERM_REASON(reason_set, reason_val) \ > (((((u64)reason_set) & GHCB_MSR_TERM_REASON_SET_MASK) << GHCB_MSR_TERM_REASON_SET_POS) | \ > ((((u64)reason_val) & GHCB_MSR_TERM_REASON_MASK) << GHCB_MSR_TERM_REASON_POS)) > +#define GHCB_MSR_TERM_REASON_SET(msr) \ > + (((msr) >> GHCB_MSR_TERM_REASON_SET_POS) & GHCB_MSR_TERM_REASON_SET_MASK) > +#define GHCB_MSR_TERM_REASON(msr) \ > + (((msr) >> GHCB_MSR_TERM_REASON_POS) & GHCB_MSR_TERM_REASON_MASK) > + > > #define GHCB_SEV_ES_REASON_GENERAL_REQUEST 0 > #define GHCB_SEV_ES_REASON_PROTOCOL_UNSUPPORTED 1 > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > index 6710d9ee2e4b..d7b3557b8dbb 100644 > --- a/arch/x86/kvm/svm/sev.c > +++ b/arch/x86/kvm/svm/sev.c > @@ -2342,16 +2342,15 @@ static bool setup_vmgexit_scratch(struct vcpu_svm *svm, bool sync, u64 len) > return true; > } > > -static void set_ghcb_msr_bits(struct vcpu_svm *svm, u64 value, u64 mask, > - unsigned int pos) > +static void set_ghcb_msr_cpuid_resp(struct vcpu_svm *svm, u64 reg, u64 value) > { > - svm->vmcb->control.ghcb_gpa &= ~(mask << pos); > - svm->vmcb->control.ghcb_gpa |= (value & mask) << pos; > -} > + u64 msr; > > -static u64 get_ghcb_msr_bits(struct vcpu_svm *svm, u64 mask, unsigned int pos) > -{ > - return (svm->vmcb->control.ghcb_gpa >> pos) & mask; > + msr = GHCB_MSR_CPUID_RESP; > + msr |= (reg & GHCB_MSR_CPUID_REG_MASK) << GHCB_MSR_CPUID_REG_POS; > + msr |= (value & GHCB_MSR_CPUID_VALUE_MASK) << GHCB_MSR_CPUID_VALUE_POS; > + > + svm->vmcb->control.ghcb_gpa = msr; I would rather have the get/set pairs be roughly symmetric, i.e. both functions or both macros, and both work on svm->vmcb->control.ghcb_gpa or both be purely functional (that may not be the correct word). I don't have a strong preference on function vs. macro. But for the second one, my preference would be to have the helper generate the value as opposed to taken and filling a pointer, e.g. to yield something like: cpuid_reg = GHCB_MSR_CPUID_REG(control->ghcb_gpa); if (cpuid_reg == 0) cpuid_value = vcpu->arch.regs[VCPU_REGS_RAX]; else if (cpuid_reg == 1) cpuid_value = vcpu->arch.regs[VCPU_REGS_RBX]; else if (cpuid_reg == 2) cpuid_value = vcpu->arch.regs[VCPU_REGS_RCX]; else cpuid_value = vcpu->arch.regs[VCPU_REGS_RDX]; control->ghcb_gpa = MAKE_GHCB_MSR_RESP(cpuid_reg, cpuid_value); The advantage is that it's obvious from the code that control->ghcb_gpa is being read _and_ written. > case GHCB_MSR_TERM_REQ: { > u64 reason_set, reason_code; > > - reason_set = get_ghcb_msr_bits(svm, > - GHCB_MSR_TERM_REASON_SET_MASK, > - GHCB_MSR_TERM_REASON_SET_POS); > - reason_code = get_ghcb_msr_bits(svm, > - GHCB_MSR_TERM_REASON_MASK, > - GHCB_MSR_TERM_REASON_POS); > + reason_set = GHCB_MSR_TERM_REASON_SET(control->ghcb_gpa); > + reason_code = GHCB_MSR_TERM_REASON(control->ghcb_gpa); > + > pr_info("SEV-ES guest requested termination: %#llx:%#llx\n", > reason_set, reason_code); > + > fallthrough; Not related to this patch, but why use fallthrough and more importantly, why is this an -EINVAL return? Why wouldn't KVM forward the request to userspace instead of returning an opaque -EINVAL? > } > default: > -- > 2.31.1 >