Received: by 2002:a05:7412:f589:b0:e2:908c:2ebd with SMTP id eh9csp1095534rdb; Wed, 1 Nov 2023 11:06:33 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH0NQz2XCkPnKaQ6NRRSY3uytv/HvESzuQrwo2SDFlvw6BUClfLFGlq+cIeoIGmX/k5nT3A X-Received: by 2002:a17:902:930c:b0:1c9:dac0:fbb3 with SMTP id bc12-20020a170902930c00b001c9dac0fbb3mr11769969plb.31.1698861992895; Wed, 01 Nov 2023 11:06:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698861992; cv=none; d=google.com; s=arc-20160816; b=QS9MDcG+BBgxv6cvSQhNjoPl8PoZBGqSBThMgLr+lNJqrMJsCfcCD/Bm4G89fyxxVm 6ssACtCdy8Zkj1SDoqiq5b7+0rBp3GqMvWNwUzS71DetU9o7H/6kgaZHWvUlZUr9wsDU tJR3jA88isEMdYplfIbzZdjpmvBM5lYYURJaXhkDobZn88SNW37rQ2jI33EakGaud2wV Wh1bRhr3JAyV4ylOyxsqbFfDi6/aFGEROaqHYu7GAAd8e/nwihKahOAfoOVMsUjoCK+o osYae55JKHxPIXIPRN/RF4MrABNtZWu41fHauYvnWZufBuPQQnwHMyywlUmnHSz6scGI 54zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:dkim-signature; bh=rL6PypGT2hlmINXu9QUwfJHSqDzRPjLPXVa5ioHlgmM=; fh=9H2JdZ4RfWqrKjgeBNKplQMSTrXHkLX7N6ZGqyjTrX8=; b=eKiGobxZbgrRp3t2gcJDRANkvTti+Gnn9JEOag2PvBhwxkUTuUnnkBjzcVyUC6gUwv 7d1LjffNtMT+0LTZNVWbCdGjbw5gp86QLzMKydunEZA6C3KtyMdZ0J+1nHgH2RGRliwW oQsthsjYPYB+sZ6F8Uu6xfCtgBXhMH/3haRY3Qkpyl2r7oOF0EdoJx9q7sPxiLXMGYYo 2atNM6kOACslNQLPu+x1NDsLpj/YMpJ+fHGc+z7ruJhJDQTNqfhhknw89y6yf8oUqS3N ThYNRk8xwKHL0O7F5gUp++sW7sLHNNINQLZNZlYuotGdjW8f496YlK6yehGPc4KPkgZg 0TVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=cV0KYCn8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 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 groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id m9-20020a170902db0900b001cc2523cf08si3617714plx.428.2023.11.01.11.06.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Nov 2023 11:06:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=cV0KYCn8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 27B3A803BDA2; Wed, 1 Nov 2023 11:06:11 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344791AbjKASFx (ORCPT + 99 others); Wed, 1 Nov 2023 14:05:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344421AbjKASFv (ORCPT ); Wed, 1 Nov 2023 14:05:51 -0400 Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DCF6C10E for ; Wed, 1 Nov 2023 11:05:45 -0700 (PDT) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-5afe220cadeso1145917b3.3 for ; Wed, 01 Nov 2023 11:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1698861945; x=1699466745; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=rL6PypGT2hlmINXu9QUwfJHSqDzRPjLPXVa5ioHlgmM=; b=cV0KYCn8U3gEavG+eISSGQWUwGWiGyKlJz0hIyUcqRq3sOyBpI1UF5gxACX7Lg9om9 Wln6PNazQdGp0Qcz52443Ku6hXwMpIBpPU2WgwOqMt75SmIkiAMAk4JIFBkDPe58XTfu PzbS1uacqXACACPptXq697KyQTYD3J0eDPkOy5VbzTBJsAOJOg3Ol7sfhcASrTuD73Qv 00XhjtsSKaXZQBCWOgyMtCCptnxr1erS2LhZBaN4w0ofwZxs7EIxpBUen5YhxPrfpotO 1CcoOPcDUPBliOvsQTV50V/hBxv7j/pAPSCVIYOdmDbfmfmLQMNLuhElBxPM6IwQtp8R 2zeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698861945; x=1699466745; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rL6PypGT2hlmINXu9QUwfJHSqDzRPjLPXVa5ioHlgmM=; b=QopwYZNf0usL3/FrPiAKD5HMALytatkGS5KCKV/W6Vc1Z53Q502HG/HI4gZ+n8a5Gg S9QL56lP+u8Bz9PD2b1W3PFh/epNbzXVO7jZtHW19bZb/g5xoQNNp+U+vDJ1ouVfyHeX EAHtiY75KLXjg59Fuyh5+tusmbanCIiSK//R1W+pCSO0aRWvsEHg/aZasSveR/YO8SJh UXjOShW9JqEinQNXkrzN7NsPub2nLmA2FmXKylTJUHiakUvXSLJMiU/+aee5J2ZnpF41 H3KMajtPxSWq/UjWHRCTtzk3Ljg1u7uC9EyF3kbWCYC8tII1EmCszScKLKkhHeRKQ4TT 3Mkw== X-Gm-Message-State: AOJu0Yzx0OICloay6R6sQsIco/42qGUXhDRSYUEwF0jUYfha8OHWqXco aSKcSmVLF6TcG7BRO7Usu19lQX6fJWc= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a81:a14c:0:b0:59b:e97e:f7e2 with SMTP id y73-20020a81a14c000000b0059be97ef7e2mr351426ywg.4.1698861945136; Wed, 01 Nov 2023 11:05:45 -0700 (PDT) Date: Wed, 1 Nov 2023 11:05:43 -0700 In-Reply-To: <2b1973ee44498039c97d4d11de3a93b0f3b1d2d8.camel@redhat.com> Mime-Version: 1.0 References: <20230914063325.85503-1-weijiang.yang@intel.com> <20230914063325.85503-15-weijiang.yang@intel.com> <2b1973ee44498039c97d4d11de3a93b0f3b1d2d8.camel@redhat.com> Message-ID: Subject: Re: [PATCH v6 14/25] KVM: x86: Load guest FPU state when access XSAVE-managed MSRs From: Sean Christopherson To: Maxim Levitsky Cc: Yang Weijiang , pbonzini@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, dave.hansen@intel.com, peterz@infradead.org, chao.gao@intel.com, rick.p.edgecombe@intel.com, john.allen@amd.com Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-8.4 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE,T_SPF_TEMPERROR, USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Wed, 01 Nov 2023 11:06:11 -0700 (PDT) On Tue, Oct 31, 2023, Maxim Levitsky wrote: > On Thu, 2023-09-14 at 02:33 -0400, Yang Weijiang wrote: > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > index 66edbed25db8..a091764bf1d2 100644 > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -133,6 +133,9 @@ static int __set_sregs2(struct kvm_vcpu *vcpu, struct kvm_sregs2 *sregs2); > > static void __get_sregs2(struct kvm_vcpu *vcpu, struct kvm_sregs2 *sregs2); > > > > static DEFINE_MUTEX(vendor_module_lock); > > +static void kvm_load_guest_fpu(struct kvm_vcpu *vcpu); > > +static void kvm_put_guest_fpu(struct kvm_vcpu *vcpu); > > + > > struct kvm_x86_ops kvm_x86_ops __read_mostly; > > > > #define KVM_X86_OP(func) \ > > @@ -4372,6 +4375,22 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info) > > } > > EXPORT_SYMBOL_GPL(kvm_get_msr_common); > > > > +static const u32 xstate_msrs[] = { > > + MSR_IA32_U_CET, MSR_IA32_PL0_SSP, MSR_IA32_PL1_SSP, > > + MSR_IA32_PL2_SSP, MSR_IA32_PL3_SSP, > > +}; > > + > > +static bool is_xstate_msr(u32 index) > > +{ > > + int i; > > + > > + for (i = 0; i < ARRAY_SIZE(xstate_msrs); i++) { > > + if (index == xstate_msrs[i]) > > + return true; > > + } > > + return false; > > +} > > The name 'xstate_msr' IMHO is not clear. > > How about naming it 'guest_fpu_state_msrs', together with adding a comment like that: Maybe xstate_managed_msrs? I'd prefer not to include "guest" because the behavior is more a property of the architecture and/or the host kernel. I understand where you're coming from, but it's the MSR *values* are part of guest state, whereas the check is a query on how KVM manages the MSR value, if that makes sense. And I really don't like "FPU". I get why the the kernel uses the "FPU" terminology, but for this check in particular I want to tie the behavior back to the architecture, i.e. provide the hint that the reason why these MSRs are special is because Intel defined them to be context switched via XSTATE. Actually, this is unnecesary bikeshedding to some extent, using an array is silly. It's easier and likely far more performant (not that that matters in this case) to use a switch statement. Is this better? /* * Returns true if the MSR in question is managed via XSTATE, i.e. is context * switched with the rest of guest FPU state. */ static bool is_xstate_managed_msr(u32 index) { switch (index) { case MSR_IA32_U_CET: case MSR_IA32_PL0_SSP ... MSR_IA32_PL3_SSP: return true; default: return false; } } /* * Read or write a bunch of msrs. All parameters are kernel addresses. * * @return number of msrs set successfully. */ static int __msr_io(struct kvm_vcpu *vcpu, struct kvm_msrs *msrs, struct kvm_msr_entry *entries, int (*do_msr)(struct kvm_vcpu *vcpu, unsigned index, u64 *data)) { bool fpu_loaded = false; int i; for (i = 0; i < msrs->nmsrs; ++i) { /* * If userspace is accessing one or more XSTATE-managed MSRs, * temporarily load the guest's FPU state so that the guest's * MSR value(s) is resident in hardware, i.e. so that KVM can * get/set the MSR via RDMSR/WRMSR. */ if (vcpu && !fpu_loaded && kvm_caps.supported_xss && is_xstate_managed_msr(entries[i].index)) { kvm_load_guest_fpu(vcpu); fpu_loaded = true; } if (do_msr(vcpu, entries[i].index, &entries[i].data)) break; } if (fpu_loaded) kvm_put_guest_fpu(vcpu); return i; }