Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp1576545ybi; Wed, 19 Jun 2019 23:47:17 -0700 (PDT) X-Google-Smtp-Source: APXvYqxe6DQ5mDnE+a2R/DH2o7L8e0DdRQwY5hZQjnhDA8lQb1/D2SwWnEIlroPa2tV9WSQ7rVCv X-Received: by 2002:a17:902:e40f:: with SMTP id ci15mr45356097plb.103.1561013237574; Wed, 19 Jun 2019 23:47:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561013237; cv=none; d=google.com; s=arc-20160816; b=zH7M8hLLIA7j1frrYIPJu3/n6CDmKDoa5SeJKCQGvmzJrzRpg0lmFCpsXMYAFDGD3k +Y2wF6FfeuyMeDCweUVPoiyxjNlnC5Mffjsf3xqZNPAZ62xneD4KVVVpxPn6vN9vqbir Bka6bj61BmUeWrJJfAelpvg3uesNsyeE9NJX+PH2nvKRaV5jrJTKNX0C/c/mDEodtms3 SNBAjMmcK82s/RP5zH2gu6lrRQMVIHbXtdXjIz88oJR+Ge+pyDYamkAqbjmMTVzqInFH N/xIG2zJAd+LqE8+3LVrq+X4co9KSXxhKwHJDCBICcWExdRxoMEhq+EH3fgfcJC3g1iT dUwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=KtXZRjOZQUo4GUGweFUtQpc11ppGctXlH18H1vES+5w=; b=FKOQVnktp3E61yOpfI657e6P/a/gEcrePmBkeiSA1ToQ1qBy+ZL22JQ+XfywexDcLm 4zyhrcGJq2vndXaq15twNprHP3Ke6RgdIuWGb2CSFsTdDP4sIbPHcuGwiu6NIoASpiSq BAkEuo+Uiu1DxEh66tufIO+a401Y+mGALj2cakLrp4qr/Ve0OIho1pbHIL+s1jWS7D17 Y4WR3MRWROsZeaiY6Nhr1qffjy5faS3bU6C38X7iGXRd/D4tO+FnLC3SnYi8C+jLvoXL eA1+cctMp9zJSsTHzVxfKwJ0pRczr3wL054tQpnjYCJvvHygf03TOD7UXLrpIq7xFi78 VfqA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 38si5238776pgt.33.2019.06.19.23.47.01; Wed, 19 Jun 2019 23:47:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726379AbfFTGq4 (ORCPT + 99 others); Thu, 20 Jun 2019 02:46:56 -0400 Received: from mga12.intel.com ([192.55.52.136]:33092 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725872AbfFTGq4 (ORCPT ); Thu, 20 Jun 2019 02:46:56 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jun 2019 23:46:55 -0700 X-IronPort-AV: E=Sophos;i="5.63,395,1557212400"; d="scan'208";a="154028475" Received: from xiaoyaol-mobl.ccr.corp.intel.com (HELO [10.239.13.123]) ([10.239.13.123]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/AES256-SHA; 19 Jun 2019 23:46:53 -0700 Subject: Re: [PATCH] KVM: vmx: Fix the broken usage of vmx_xsaves_supported To: Wanpeng Li , Tao Xu Cc: Paolo Bonzini , Radim Krcmar , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , kvm , LKML References: <20190620050301.1149-1-tao3.xu@intel.com> From: Xiaoyao Li Message-ID: Date: Thu, 20 Jun 2019 14:46:50 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/20/2019 2:40 PM, Wanpeng Li wrote: > Hi, > On Thu, 20 Jun 2019 at 13:06, Tao Xu wrote: >> >> The helper vmx_xsaves_supported() returns the bit value of >> SECONDARY_EXEC_XSAVES in vmcs_config.cpu_based_2nd_exec_ctrl, which >> remains unchanged true if vmcs supports 1-setting of this bit after >> setup_vmcs_config(). It should check the guest's cpuid not this >> unchanged value when get/set msr. >> >> Besides, vmx_compute_secondary_exec_control() adjusts >> SECONDARY_EXEC_XSAVES bit based on guest cpuid's X86_FEATURE_XSAVE >> and X86_FEATURE_XSAVES, it should use updated value to decide whether >> set XSS_EXIT_BITMAP. >> >> Co-developed-by: Xiaoyao Li >> Signed-off-by: Xiaoyao Li >> Signed-off-by: Tao Xu >> --- >> arch/x86/kvm/vmx/vmx.c | 8 +++++--- >> 1 file changed, 5 insertions(+), 3 deletions(-) >> >> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c >> index b93e36ddee5e..935cf72439a9 100644 >> --- a/arch/x86/kvm/vmx/vmx.c >> +++ b/arch/x86/kvm/vmx/vmx.c >> @@ -1721,7 +1721,8 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) >> return vmx_get_vmx_msr(&vmx->nested.msrs, msr_info->index, >> &msr_info->data); >> case MSR_IA32_XSS: >> - if (!vmx_xsaves_supported()) >> + if (!guest_cpuid_has(vcpu, X86_FEATURE_XSAVE) || >> + !guest_cpuid_has(vcpu, X86_FEATURE_XSAVES)) >> return 1; >> msr_info->data = vcpu->arch.ia32_xss; >> break; >> @@ -1935,7 +1936,8 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) >> return 1; >> return vmx_set_vmx_msr(vcpu, msr_index, data); >> case MSR_IA32_XSS: >> - if (!vmx_xsaves_supported()) >> + if (!guest_cpuid_has(vcpu, X86_FEATURE_XSAVE) || >> + !guest_cpuid_has(vcpu, X86_FEATURE_XSAVES)) >> return 1; > > Not complete true. > >> /* >> * The only supported bit as of Skylake is bit 8, but >> @@ -4094,7 +4096,7 @@ static void vmx_vcpu_setup(struct vcpu_vmx *vmx) >> >> set_cr4_guest_host_mask(vmx); >> >> - if (vmx_xsaves_supported()) >> + if (vmx->secondary_exec_control & SECONDARY_EXEC_XSAVES) >> vmcs_write64(XSS_EXIT_BITMAP, VMX_XSS_EXIT_BITMAP); > > This is not true. > > SDM 24.6.20: > On processors that support the 1-setting of the “enable > XSAVES/XRSTORS” VM-execution control, the VM-execution control fields > include a 64-bit XSS-exiting bitmap. > > It depends on whether or not processors support the 1-setting instead > of “enable XSAVES/XRSTORS” is 1 in VM-exection control field. Anyway, Yes, whether this field exist or not depends on whether processors support the 1-setting. But if "enable XSAVES/XRSTORS" is clear to 0, XSS_EXIT_BITMAP doesn't work. I think in this case, there is no need to set this vmcs field? > I will send a patch to fix the msr read/write for commit > 203000993de5(kvm: vmx: add MSR logic for XSAVES), thanks for the > report. > > Regards, > Wanpeng Li >