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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4A837C636D4 for ; Tue, 31 Jan 2023 21:07:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232007AbjAaVHz (ORCPT ); Tue, 31 Jan 2023 16:07:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40220 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231834AbjAaVHw (ORCPT ); Tue, 31 Jan 2023 16:07:52 -0500 Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A3701B472 for ; Tue, 31 Jan 2023 13:07:51 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id g68so10985124pgc.11 for ; Tue, 31 Jan 2023 13:07:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Up7/zvDdjUz1Pcl1Rjcqj9BQdupVezuRTStHZScQfAA=; b=rmIT1jIZRk8hQ3tu2ptW5zSnxr4aPhAb2XBN08+YjY4NUbUv3Z1DD9vzsx6igrkfZg O32HcLg9Ef5Jh+Z1NNAFpQNQoM4LLvzKKNU4IjP6yXro8bGPMDPzJ7FZJUbRsyVeuOGY Y4xY91h9yfK21L8nAepgJQdsmTJPYlmSxScUBiMdS9Rq6V4xHqrjqY2bFjW2Vl8JJrl8 6bQx8ncWgz9qJ6I/8/Q1Ld8+QYA2cM/8SUU+RvlTb7EfuYGlg88Vx/ApgiPzcxA+AwxS 6GwKoonBNGseVBx9qyJnQuODj2hr5AKOI3SXcGdm4i9tvzGRacKKKVdz+C1WWrtCGsHY dwMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Up7/zvDdjUz1Pcl1Rjcqj9BQdupVezuRTStHZScQfAA=; b=AfvykgEeG+z+veoKoevWNpRtlW7KQtLcVv6uy+uNtEg3FTqe+JACe57YyyLLrd9Wya lmiMDUF+UOFgrxVSqgrJJ7Wn0nEIjEE2Arasx0PwoJTs+nkfcffR4Q2TAqnjpY4fwat1 3rJNZEEx/U19kqEDgeJH7UBCIrhfMfq26hExXR2+UtloK566tl/AE+YYaPZUODHYlX8w hkVYE/pyHjp3AVDYARPGmS+V63AGNkT2ScKxvrezRhPoITVJPU6NTih1ZWNkDQahC79m 8H6aoVDjit9UetzdZNDMFrjHNcP1ZEES0BdIGePZyp31PN8G09oweX8YVZE1vZS2KIqx vf7A== X-Gm-Message-State: AO0yUKWAZgduN3NxgTO7Y33EFcQ68bgQHlcoN15UorwDqskwXPNbzjzY 0U3g5+YibO/HCXtRHCYk1+wLwQ== X-Google-Smtp-Source: AK7set/UeC8+PrNBMRcAicmB2v06KLiBgEVfW/rBqKSq3VcmoSyU+lmwsGCajCVhHYyfaE1vyJWfFA== X-Received: by 2002:a05:6a00:784:b0:576:9252:d06 with SMTP id g4-20020a056a00078400b0057692520d06mr127327pfu.0.1675199270958; Tue, 31 Jan 2023 13:07:50 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id 144-20020a621996000000b0058bcb42dd1asm9920762pfz.111.2023.01.31.13.07.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Jan 2023 13:07:50 -0800 (PST) Date: Tue, 31 Jan 2023 21:07:46 +0000 From: Sean Christopherson To: Maxim Levitsky Cc: Santosh Shukla , kvm@vger.kernel.org, Sandipan Das , Paolo Bonzini , Jim Mattson , Peter Zijlstra , Dave Hansen , Borislav Petkov , Pawan Gupta , Thomas Gleixner , Ingo Molnar , Josh Poimboeuf , Daniel Sneddon , Jiaxi Chen , Babu Moger , linux-kernel@vger.kernel.org, Jing Liu , Wyes Karny , x86@kernel.org, "H. Peter Anvin" Subject: Re: [PATCH v2 06/11] KVM: SVM: add wrappers to enable/disable IRET interception Message-ID: References: <20221129193717.513824-1-mlevitsk@redhat.com> <20221129193717.513824-7-mlevitsk@redhat.com> <41abb37b-c74a-f2cf-c0ce-74d5d6487e92@amd.com> <181f437164296e19683f086c11bf64c11a3f380e.camel@redhat.com> <70078abb-f8b7-cd33-5bdd-bc6ee44c0bd3@amd.com> <06d12050eece922e786b7bee1254698466c6d3d4.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06d12050eece922e786b7bee1254698466c6d3d4.camel@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 08, 2022, Maxim Levitsky wrote: > On Thu, 2022-12-08 at 17:39 +0530, Santosh Shukla wrote: > > > > On 12/6/2022 5:44 PM, Maxim Levitsky wrote: > > > > > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > > > > > index 512b2aa21137e2..cfed6ab29c839a 100644 > > > > > --- a/arch/x86/kvm/svm/svm.c > > > > > +++ b/arch/x86/kvm/svm/svm.c > > > > > @@ -2468,16 +2468,29 @@ static int task_switch_interception(struct kvm_vcpu *vcpu) > > > > > has_error_code, error_code); > > > > > } > > > > > > > > > > +static void svm_disable_iret_interception(struct vcpu_svm *svm) > > > > > +{ > > > > > + if (!sev_es_guest(svm->vcpu.kvm)) > > > > > + svm_clr_intercept(svm, INTERCEPT_IRET); > > > > > +} > > > > > + > > > > > +static void svm_enable_iret_interception(struct vcpu_svm *svm) > > > > > +{ > > > > > + if (!sev_es_guest(svm->vcpu.kvm)) > > > > > + svm_set_intercept(svm, INTERCEPT_IRET); > > > > > +} > > > > > + > > > > > > > > nits: > > > > s/_iret_interception / _iret_intercept > > > > does that make sense? > > > > > > Makes sense. I would rather go with svm_{clr,set}_iret_intercept(). I don't particularly like the SVM naming scheme, but I really dislike inconsistent naming. If we want to clean up naming, I would love unify VMX and SVM nomenclature for things like this. > > > I can also move this to svm.h near the svm_set_intercept(), I think > > > it better a better place for this function there if no objections. > > > > > I think current approach is fine since function used in svm.c only. but I have > > no strong opinion on moving to svm.h either ways. > > I also think so, just noticed something in case there are any objections. My vote is to keep it in svm.c unless we anticipate usage outside of svm.h. Keeping the implementation close to the usage makes it easer to understand what's going on, especially for something like this where there's a bit of "hidden" logic for SEV-ES.