Received: by 2002:a05:7412:f589:b0:e2:908c:2ebd with SMTP id eh9csp413382rdb; Tue, 31 Oct 2023 10:47:19 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGsZxVrUKlZ0+hkfFiTumm8+bpIAsseGwbjX2swPR6q6aDOabGlLKevQmuabUcWcmUoIn3d X-Received: by 2002:a17:90a:440d:b0:27d:9b5:d6f8 with SMTP id s13-20020a17090a440d00b0027d09b5d6f8mr9110006pjg.49.1698774439029; Tue, 31 Oct 2023 10:47:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698774439; cv=none; d=google.com; s=arc-20160816; b=tlHG7HHLKKj7kFqZwoL5LMJSs/L8pGHPO6ZgzRWQgRED0VTGSNqcdPdT6cd0ANUoSU Kmgcg1OqVmqzk0rkvWEVqq6udWpcrALO1Vq/JAaR2Tqkbcjvo7nGC8MYV+qZzmU3Jjx4 6q1+bBDfAaf69X5XMJ963STK5wdC3SfVBUBn/IH4UM134q/dEFlZw2xaQt3/0bHJ3GEk Mr8e4T5zQLCjfAdPHfAQvV4TOOU4fPu4bqcd0+0h/HWB2J5h6BzRqHD4kb9WgHbfsX4t c5L0ZSRyWWrN31FozOX5PgD3v7wK5hWrNUpFMUaaZ3LP46WgVUJhK5rnwbKIvpq+ze+4 JRMA== 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=9eJnmdZvlfUltYnnbp/aAXrD+JoS5JYlY6ATNZvCHFI=; fh=+Fohcjfhju91Ks65dYUxnAk8Iqhjo5nHmNS78Sf+bHk=; b=acZQkLxS9RIdjWsRXQ7bSxD+sBpwxwKFeGd3Ut7/0m81LsP6LcunkrIFQQ4s5J4hHg MCbl0i+3QKsVoa4GtgjsXxsmTRUiLq9Zg49qIKqG4kfYygir5h8vXK4jycouUYi2by65 IUqU3X6VkJ/wuk3eTWPtvgS82GaibWj0QMB9caGUqo5ersNvVqkq3VpDkolPsr5mv8hR thZkmbD618n6LyDSU95k31D+UQ1uvqlffI35jFhtvIj6guFcsFELhPthJtskZlkoBbaW 2BfIEanOgCZx4d7ySIX7Tj4JV7d+mybS/M065WlqB/MdZrhcr9M6Wz+a5i9VCP0ucEDT trig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="g/bw9ZDP"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 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 agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id mi14-20020a17090b4b4e00b0027cead6f6b4si311807pjb.1.2023.10.31.10.47.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Oct 2023 10:47:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="g/bw9ZDP"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 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 agentk.vger.email (Postfix) with ESMTP id 138F78030E4A; Tue, 31 Oct 2023 10:47:16 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376402AbjJaRrL (ORCPT + 99 others); Tue, 31 Oct 2023 13:47:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376395AbjJaRrK (ORCPT ); Tue, 31 Oct 2023 13:47:10 -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 8285AE8 for ; Tue, 31 Oct 2023 10:46:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1698774379; 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=9eJnmdZvlfUltYnnbp/aAXrD+JoS5JYlY6ATNZvCHFI=; b=g/bw9ZDPyIS0ezI4Wa8lxOfa4J3Dz+YAYHajGjsrsLuiB+3zsw9ZPzY2zNv/DAK8c50tJN w6ye7jM7ZhNESQB7wbB4vRKVudpDA8QzT7UFY8Z2DieYwLnl4P5F55CI4Zk5AlU+CgKMhK 0gRGhUwhBZY2FpUUmk1gFPyYqsEmeVk= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-665-FNVSUj22M7K9zNw2I5zTFQ-1; Tue, 31 Oct 2023 13:46:17 -0400 X-MC-Unique: FNVSUj22M7K9zNw2I5zTFQ-1 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-32f798bc811so1896680f8f.1 for ; Tue, 31 Oct 2023 10:46:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698774376; x=1699379176; 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=9eJnmdZvlfUltYnnbp/aAXrD+JoS5JYlY6ATNZvCHFI=; b=Q8aHtRHI8yPF3OQqeKma9FFazMbTlpzZMNxsA/hN/Xkm9+F2v0ars6uYXiXLqOZ+4A 4BjNEey3vBDkbqq9zKB7FJmV9pgi/PREGRa/DpOAjVSyXFJHrp22M8tdNfuJGHOVvx0U mK3iMvC/Rtvqhbunysn9hgDLlwz9y1htEwTkOLRdHCRsVV4F2NC+tXLLCqboI5DT1CGN OI7GeQb+RjrTnbBOHRjHdpob2bbiexll10RzG7y4/BH2YW4TfnVlinsYXtXupxa5VLNu x6ws83d6/vmM9fYjhOXDzCdVHaqCTc80KRVoxu11+dthM3Yel9hxRnKQLrYBgd4xpbqD vPRg== X-Gm-Message-State: AOJu0YwUA5ALZ05vPby7NnIcWpuEGVMhJtnUAizjp1//0lWrKya9+o/g 23B0M9lCX1bhA3iwmDPcxZ+iyUksGtj/Ye24cYS7bWkwvXwMVXwPyEDvla6FA+vUtgMltlfQt2s VGzxjISpQdVSeaMEmDrgkd4ft X-Received: by 2002:adf:d1e8:0:b0:32f:7d50:267e with SMTP id g8-20020adfd1e8000000b0032f7d50267emr8510235wrd.9.1698774376199; Tue, 31 Oct 2023 10:46:16 -0700 (PDT) X-Received: by 2002:adf:d1e8:0:b0:32f:7d50:267e with SMTP id g8-20020adfd1e8000000b0032f7d50267emr8510228wrd.9.1698774376009; Tue, 31 Oct 2023 10:46:16 -0700 (PDT) Received: from starship ([89.237.100.246]) by smtp.gmail.com with ESMTPSA id g18-20020a5d5412000000b0032da022855fsm1990174wrv.111.2023.10.31.10.46.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Oct 2023 10:46:15 -0700 (PDT) Message-ID: <96c30a78fa95071e87045b7293c2cf796d4182a0.camel@redhat.com> Subject: Re: [PATCH v6 09/25] KVM: x86: Rework cpuid_get_supported_xcr0() to operate on vCPU data 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 Date: Tue, 31 Oct 2023 19:46:13 +0200 In-Reply-To: <20230914063325.85503-10-weijiang.yang@intel.com> References: <20230914063325.85503-1-weijiang.yang@intel.com> <20230914063325.85503-10-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=-1.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,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 agentk.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 (agentk.vger.email [0.0.0.0]); Tue, 31 Oct 2023 10:47:16 -0700 (PDT) On Thu, 2023-09-14 at 02:33 -0400, Yang Weijiang wrote: > From: Sean Christopherson > > Rework and rename cpuid_get_supported_xcr0() to explicitly operate on vCPU > state, i.e. on a vCPU's CPUID state. Prior to commit 275a87244ec8 ("KVM: > x86: Don't adjust guest's CPUID.0x12.1 (allowed SGX enclave XFRM)"), KVM > incorrectly fudged guest CPUID at runtime, Can you explain how commit 275a87244ec8 relates to this patch? > which in turn necessitated > massaging the incoming CPUID state for KVM_SET_CPUID{2} so as not to run > afoul of kvm_cpuid_check_equal(). Can you link the commit that added this 'massaging' and explain on how this relates to this patch? Can you explain what is the problem that this patch is trying to solve? Is it really allowed in x86 spec to have different supported mask of XCR0 bits on different CPUs (assuming all CPUs of the same type)? If true, does KVM supports it? Assuming that the answer to the above questions is no, won't this patch make it easier to break this rule and thus make it easier to introduce a bug? Best regards, Maxim Levitsky > > Opportunistically move the helper below kvm_update_cpuid_runtime() to make > it harder to repeat the mistake of querying supported XCR0 for runtime > updates. > > No functional change intended. > > Signed-off-by: Sean Christopherson > Signed-off-by: Yang Weijiang > --- > arch/x86/kvm/cpuid.c | 33 ++++++++++++++++----------------- > 1 file changed, 16 insertions(+), 17 deletions(-) > > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > index 0544e30b4946..7c3e4a550ca7 100644 > --- a/arch/x86/kvm/cpuid.c > +++ b/arch/x86/kvm/cpuid.c > @@ -247,21 +247,6 @@ void kvm_update_pv_runtime(struct kvm_vcpu *vcpu) > vcpu->arch.pv_cpuid.features = best->eax; > } > > -/* > - * Calculate guest's supported XCR0 taking into account guest CPUID data and > - * KVM's supported XCR0 (comprised of host's XCR0 and KVM_SUPPORTED_XCR0). > - */ > -static u64 cpuid_get_supported_xcr0(struct kvm_cpuid_entry2 *entries, int nent) > -{ > - struct kvm_cpuid_entry2 *best; > - > - best = cpuid_entry2_find(entries, nent, 0xd, 0); > - if (!best) > - return 0; > - > - return (best->eax | ((u64)best->edx << 32)) & kvm_caps.supported_xcr0; > -} > - > static void __kvm_update_cpuid_runtime(struct kvm_vcpu *vcpu, struct kvm_cpuid_entry2 *entries, > int nent) > { > @@ -312,6 +297,21 @@ void kvm_update_cpuid_runtime(struct kvm_vcpu *vcpu) > } > EXPORT_SYMBOL_GPL(kvm_update_cpuid_runtime); > > +/* > + * Calculate guest's supported XCR0 taking into account guest CPUID data and > + * KVM's supported XCR0 (comprised of host's XCR0 and KVM_SUPPORTED_XCR0). > + */ > +static u64 vcpu_get_supported_xcr0(struct kvm_vcpu *vcpu) > +{ > + struct kvm_cpuid_entry2 *best; > + > + best = kvm_find_cpuid_entry_index(vcpu, 0xd, 0); > + if (!best) > + return 0; > + > + return (best->eax | ((u64)best->edx << 32)) & kvm_caps.supported_xcr0; > +} > + > static bool kvm_cpuid_has_hyperv(struct kvm_cpuid_entry2 *entries, int nent) > { > struct kvm_cpuid_entry2 *entry; > @@ -357,8 +357,7 @@ static void kvm_vcpu_after_set_cpuid(struct kvm_vcpu *vcpu) > kvm_apic_set_version(vcpu); > } > > - vcpu->arch.guest_supported_xcr0 = > - cpuid_get_supported_xcr0(vcpu->arch.cpuid_entries, vcpu->arch.cpuid_nent); > + vcpu->arch.guest_supported_xcr0 = vcpu_get_supported_xcr0(vcpu); > > /* > * FP+SSE can always be saved/restored via KVM_{G,S}ET_XSAVE, even if