Received: by 2002:a05:7412:f589:b0:e2:908c:2ebd with SMTP id eh9csp415956rdb; Tue, 31 Oct 2023 10:52:27 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGKt7G4saNyr9QjcJx4u7258T8rBzBRG/u50m2pETw8/E8E7buSVjfAAhlPUTppvBXVWe8k X-Received: by 2002:a17:902:cec8:b0:1cc:7100:2d62 with SMTP id d8-20020a170902cec800b001cc71002d62mr1335684plg.39.1698774747157; Tue, 31 Oct 2023 10:52:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698774747; cv=none; d=google.com; s=arc-20160816; b=ZgoNnbLm9KZsvbqjWEZS7tCtE7B6GW0g1+Q5Vc0EnNsCBMXuvpqAixZliv1kOhLUGm pjeeDvg7gHxVOdW5ytcMQChsHkVk9eFQqB3nxSW4NhUqTO1bbcZLqFfplVRfMfqc0piU jSwVCQXIccmVpGpRuFUJumZej/YABFXui1SvzKHmpGqHA3i+mKfQZRPdeeB7eA5rRblD E8CkOkBN1c9i1hEJHBLouA7gu3MqPRYmPBAUcHD7wGPMyyuKnMCVvfrWBmiXp+peDmF4 Il/5WIcFoHNxDY1IqTkYWlKI3KAvvg3v+CWKn+nQmc9fgPf+ghqBx/KEzY1Appu7IxfE VgHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=SG+40GpplkvNW1CAOdJBVH5eVU8uZEgWxfsItEyklhU=; fh=W5fELU5f4LMNQ68kJ2esApt9P2vYK/4mM7UIvyhV69g=; b=MBPA1tXDHlPTARKZVoVvpDjO5gQvhw9hFzsS8QSwXuJZNOr0Bj5PjISOQAWlKEiQx7 9gDHid0PiNOCEqdO1fxc8X/rwbNDgE+hg3riDx6PZVofmPvubFG2ySioXlRQMLXERAwf 5Wg774qUgyQ/BR5G8MlypeTAteRSgKMdaJ2rbkdrAMmWq3NuxsoR5CHfKW+IFYoD6fGu 7B8GXk6waCdQKR+jTz+KF71vxq0u6bo/nKLw49BhzK43LGQ7eaornk5b1i/23wNFAusF AipQtFuxSPVl/OL/Xjru/mXSQKeGKOA/ntjKjImHaqhAhX1E63uZm2kMjBPo7ktxrWOT seEA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=V5rI8xJc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id b2-20020a170903228200b001cc31c96c70si1326759plh.330.2023.10.31.10.52.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Oct 2023 10:52:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=V5rI8xJc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 9D65280E0699; Tue, 31 Oct 2023 10:52:25 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347018AbjJaRwX (ORCPT + 99 others); Tue, 31 Oct 2023 13:52:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54312 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346995AbjJaRwV (ORCPT ); Tue, 31 Oct 2023 13:52:21 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0AFF8A2 for ; Tue, 31 Oct 2023 10:51:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1698774689; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SG+40GpplkvNW1CAOdJBVH5eVU8uZEgWxfsItEyklhU=; b=V5rI8xJcp4BuXPoOd6uJtPEQKpwbRYAW87ToqE8drn/1KipJiK4/uvgpid9dLmUXrth2L4 a7Xv9BmQOA6M2IhBtAczCEu5Qa3ZEy0S7zkIg+6+KBvc8YZJ34B0M6KOYJ8NrOJJyGV0n+ 0AmBbbAgS6BbsM9jPnmfiZ3Fxwb2Gio= Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-29-faz2wRedN62_q96RTFd_kg-1; Tue, 31 Oct 2023 13:51:07 -0400 X-MC-Unique: faz2wRedN62_q96RTFd_kg-1 Received: by mail-lf1-f71.google.com with SMTP id 2adb3069b0e04-507b0270b7fso6375844e87.3 for ; Tue, 31 Oct 2023 10:51:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698774666; x=1699379466; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=SG+40GpplkvNW1CAOdJBVH5eVU8uZEgWxfsItEyklhU=; b=O3R+9Q49EN0hb//oG2QbwI0h+6ZPBUeNqcahDsuVXleY0rCbWMkZH8Puw8e0yihdGm x7Ed67fhuyprElaI8Gx+ffRaXihV6RdLJ/RVBl8U5pD2Dd8CRBE/R1LXtB5S26vOUJui dTM17f1cn6P1g8sIwRIWHdqTdw34bj4eY3HDcF4WBz9dOChhgLYIH2dr+73lHyo83Mg+ QrHfW/VUC8n+db+vogCzVIqJRDnczKiNDw2CmUUpVy9z3uH24DeNdO90VQDpHTUL6Vgn I+I6xjMMNC3nU0e4cAzEXv06jjeye9ZGwYB5PbrKcq7DXLr9NNJUGFnwgRNU1SVWmRkS XDTA== X-Gm-Message-State: AOJu0YwoXwMcF6G0k4Rt2R+83M1duJzwuugXeAQQ35/hUsHJOOGlJ4CW hDLKlLFHzW0uyUcPWWMHSmtJiLhpjFrBavIyyj/tQuPNVHo4B7XflP4trEK+r2Epu6m1SZ/YbnD di9vw0neZUvTc7GE3SvAFA8ny+oi1SbBs X-Received: by 2002:a2e:990a:0:b0:2bc:f41a:d9bc with SMTP id v10-20020a2e990a000000b002bcf41ad9bcmr10231306lji.25.1698774665836; Tue, 31 Oct 2023 10:51:05 -0700 (PDT) X-Received: by 2002:a2e:990a:0:b0:2bc:f41a:d9bc with SMTP id v10-20020a2e990a000000b002bcf41ad9bcmr10231290lji.25.1698774665475; Tue, 31 Oct 2023 10:51:05 -0700 (PDT) Received: from starship ([89.237.100.246]) by smtp.gmail.com with ESMTPSA id q9-20020a7bce89000000b0040523bef620sm1087120wmj.0.2023.10.31.10.51.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Oct 2023 10:51:05 -0700 (PDT) Message-ID: <5c5eb1cc92d05fb7717fe3480aeb7b20e7842d05.camel@redhat.com> Subject: Re: [PATCH v6 12/25] KVM: x86: Refresh CPUID on write to guest MSR_IA32_XSS From: Maxim Levitsky To: Yang Weijiang , seanjc@google.com, pbonzini@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Cc: dave.hansen@intel.com, peterz@infradead.org, chao.gao@intel.com, rick.p.edgecombe@intel.com, john.allen@amd.com, Zhang Yi Z Date: Tue, 31 Oct 2023 19:51:03 +0200 In-Reply-To: <20230914063325.85503-13-weijiang.yang@intel.com> References: <20230914063325.85503-1-weijiang.yang@intel.com> <20230914063325.85503-13-weijiang.yang@intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 31 Oct 2023 10:52:25 -0700 (PDT) On Thu, 2023-09-14 at 02:33 -0400, Yang Weijiang wrote: > Update CPUID.(EAX=0DH,ECX=1).EBX to reflect current required xstate size > due to XSS MSR modification. > CPUID(EAX=0DH,ECX=1).EBX reports the required storage size of all enabled > xstate features in (XCR0 | IA32_XSS). The CPUID value can be used by guest > before allocate sufficient xsave buffer. > > Note, KVM does not yet support any XSS based features, i.e. supported_xss > is guaranteed to be zero at this time. > > Opportunistically modify XSS write access logic as: if !guest_cpuid_has(), > write initiated from host is allowed iff the write is reset operaiton, > i.e., data == 0, reject host_initiated non-reset write and any guest write. The commit message is not clear and somewhat misleading because it forces the reader to parse the whole patch before one could understand what '!guest_cpuid_has()' means. Also I don't think that the term 'reset operation' is a good choice, because it is too closely related to vCPU reset IMHO. Let's at least call it 'reset to a default value' or something like that. Also note that 0 is not always the default/reset value of an MSR. I suggest this instead: "If XSAVES is not enabled in the guest CPUID, forbid setting IA32_XSS msr to anything but 0, even if the write is host initiated." Also, isn't this change is at least in theory not backward compatible? While KVM didn't report IA32_XSS as one needing save/restore, the userspace could before this patch set the IA32_XSS to any value, now it can't. Maybe it's safer to allow to set any value, ignore the set value and issue a WARN_ON_ONCE or something? Finally, I think that this change is better to be done in a separate patch because it is unrelated and might not even be backward compatible. Best regards, Maxim Levitsky > > Suggested-by: Sean Christopherson > Co-developed-by: Zhang Yi Z > Signed-off-by: Zhang Yi Z > Signed-off-by: Yang Weijiang > --- > arch/x86/include/asm/kvm_host.h | 1 + > arch/x86/kvm/cpuid.c | 15 ++++++++++++++- > arch/x86/kvm/x86.c | 13 +++++++++---- > 3 files changed, 24 insertions(+), 5 deletions(-) > > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h > index 0fc5e6312e93..d77b030e996c 100644 > --- a/arch/x86/include/asm/kvm_host.h > +++ b/arch/x86/include/asm/kvm_host.h > @@ -803,6 +803,7 @@ struct kvm_vcpu_arch { > > u64 xcr0; > u64 guest_supported_xcr0; > + u64 guest_supported_xss; > > struct kvm_pio_request pio; > void *pio_data; > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > index 1f206caec559..4e7a820cba62 100644 > --- a/arch/x86/kvm/cpuid.c > +++ b/arch/x86/kvm/cpuid.c > @@ -275,7 +275,8 @@ static void __kvm_update_cpuid_runtime(struct kvm_vcpu *vcpu, struct kvm_cpuid_e > best = cpuid_entry2_find(entries, nent, 0xD, 1); > if (best && (cpuid_entry_has(best, X86_FEATURE_XSAVES) || > cpuid_entry_has(best, X86_FEATURE_XSAVEC))) > - best->ebx = xstate_required_size(vcpu->arch.xcr0, true); > + best->ebx = xstate_required_size(vcpu->arch.xcr0 | > + vcpu->arch.ia32_xss, true); > > best = __kvm_find_kvm_cpuid_features(vcpu, entries, nent); > if (kvm_hlt_in_guest(vcpu->kvm) && best && > @@ -312,6 +313,17 @@ static u64 vcpu_get_supported_xcr0(struct kvm_vcpu *vcpu) > return (best->eax | ((u64)best->edx << 32)) & kvm_caps.supported_xcr0; > } > > +static u64 vcpu_get_supported_xss(struct kvm_vcpu *vcpu) > +{ > + struct kvm_cpuid_entry2 *best; > + > + best = kvm_find_cpuid_entry_index(vcpu, 0xd, 1); > + if (!best) > + return 0; > + > + return (best->ecx | ((u64)best->edx << 32)) & kvm_caps.supported_xss; > +} Same question as one for patch that added vcpu_get_supported_xcr0() Why to have per vCPU supported XSS if we assume that all CPUs have the same CPUID? I mean I am not against supporting hybrid CPU models, but KVM currently doesn't support this and this creates illusion that it does. > + > static bool kvm_cpuid_has_hyperv(struct kvm_cpuid_entry2 *entries, int nent) > { > struct kvm_cpuid_entry2 *entry; > @@ -358,6 +370,7 @@ static void kvm_vcpu_after_set_cpuid(struct kvm_vcpu *vcpu) > } > > vcpu->arch.guest_supported_xcr0 = vcpu_get_supported_xcr0(vcpu); > + vcpu->arch.guest_supported_xss = vcpu_get_supported_xss(vcpu); > > /* > * FP+SSE can always be saved/restored via KVM_{G,S}ET_XSAVE, even if > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 1258d1d6dd52..9a616d84bd39 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -3795,20 +3795,25 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info) > vcpu->arch.ia32_tsc_adjust_msr += adj; > } > break; > - case MSR_IA32_XSS: > - if (!msr_info->host_initiated && > - !guest_cpuid_has(vcpu, X86_FEATURE_XSAVES)) > + case MSR_IA32_XSS: { > + bool host_msr_reset = msr_info->host_initiated && data == 0; > + > + if (!guest_cpuid_has(vcpu, X86_FEATURE_XSAVES) && > + (!host_msr_reset || !msr_info->host_initiated)) > return 1; > /* > * KVM supports exposing PT to the guest, but does not support > * IA32_XSS[bit 8]. Guests have to use RDMSR/WRMSR rather than > * XSAVES/XRSTORS to save/restore PT MSRs. > */ Just in case.... TODO > - if (data & ~kvm_caps.supported_xss) > + if (data & ~vcpu->arch.guest_supported_xss) > return 1; > + if (vcpu->arch.ia32_xss == data) > + break; > vcpu->arch.ia32_xss = data; > kvm_update_cpuid_runtime(vcpu); > break; > + } > case MSR_SMI_COUNT: > if (!msr_info->host_initiated) > return 1;