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 X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 293C4CA9EA0 for ; Tue, 22 Oct 2019 20:13:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E348D21783 for ; Tue, 22 Oct 2019 20:13:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389292AbfJVUNZ (ORCPT ); Tue, 22 Oct 2019 16:13:25 -0400 Received: from mga02.intel.com ([134.134.136.20]:46875 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387645AbfJVUNZ (ORCPT ); Tue, 22 Oct 2019 16:13:25 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Oct 2019 13:13:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,217,1569308400"; d="scan'208";a="188017062" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.41]) by orsmga007.jf.intel.com with ESMTP; 22 Oct 2019 13:13:21 -0700 Date: Tue, 22 Oct 2019 13:13:21 -0700 From: Sean Christopherson To: Yang Weijiang Cc: Jim Mattson , kvm list , LKML , Paolo Bonzini , "Michael S. Tsirkin" , Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [PATCH v7 5/7] kvm: x86: Add CET CR4 bit and XSS support Message-ID: <20191022201321.GN2343@linux.intel.com> References: <20190927021927.23057-1-weijiang.yang@intel.com> <20190927021927.23057-6-weijiang.yang@intel.com> <20191017195642.GJ20903@linux.intel.com> <20191018015802.GD2286@local-michael-cet-test> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191018015802.GD2286@local-michael-cet-test> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 18, 2019 at 09:58:02AM +0800, Yang Weijiang wrote: > On Thu, Oct 17, 2019 at 12:56:42PM -0700, Sean Christopherson wrote: > > On Wed, Oct 02, 2019 at 12:05:23PM -0700, Jim Mattson wrote: > > > > + u64 kvm_xss = kvm_supported_xss(); > > > > + > > > > + best->ebx = > > > > + xstate_required_size(vcpu->arch.xcr0 | kvm_xss, true); > > > > > > Shouldn't this size be based on the *current* IA32_XSS value, rather > > > than the supported IA32_XSS bits? (i.e. > > > s/kvm_xss/vcpu->arch.ia32_xss/) > > > > Ya. > > > I'm not sure if I understand correctly, kvm_xss is what KVM supports, > but arch.ia32_xss reflects what guest currently is using, shoudn't CPUID > report what KVM supports instead of current status? > Will CPUID match current IA32_XSS status if guest changes it runtime? Not in this case. Select CPUID output is dependent on current state as opposed to being a constant defind by hardware. Per the SDM, EBX is: The size in bytes of the XSAVE area containing all states enabled by XCRO | IA32_XSS Since KVM is emulating CPUID for the guest, XCR0 and IA32_XSS in this context refers to the guest's current/actual XCR0/IA32_XSS values. The purpose of this behavior is so that software can call CPUID to query the actual amount of memory that is needed for XSAVE(S), as opposed to the absolute max size that _might_ be needed. MONITOR/MWAIT is the other case that comes to mind where CPUID dynamically reflects configured state, e.g. MWAIT is reported as unsupported if it's disabled via IA32_MISC_ENABLE MSR.