From patchwork Wed Feb 15 08:49:18 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yi Sun X-Patchwork-Id: 9573601 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 6E19C60493 for ; Wed, 15 Feb 2017 08:55:49 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5FE9F28448 for ; Wed, 15 Feb 2017 08:55:49 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 53C722844C; Wed, 15 Feb 2017 08:55:49 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 993D128448 for ; Wed, 15 Feb 2017 08:55:48 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cdvKg-0007CS-RM; Wed, 15 Feb 2017 08:53:02 +0000 Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cdvKf-0007B9-R8 for xen-devel@lists.xenproject.org; Wed, 15 Feb 2017 08:53:01 +0000 Received: from [193.109.254.147] by server-3.bemta-6.messagelabs.com id 2B/41-22349-DE614A85; Wed, 15 Feb 2017 08:53:01 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRWlGSWpSXmKPExsXS1tYhoftWbEm EwaTNTBbft0xmcmD0OPzhCksAYxRrZl5SfkUCa8aqKUuYCzqdK97O+sPewPhcv4uRk0NIYBqj xLvdvCC2hACvxJFlM1gh7ACJn5fb2boYuYBqGhglnmzZzwySYBNQl3j8tYcJxBYRUJK4t2oyE 0gRs8AiJokVk76zgSSEBXwkPp9uYASxWQRUJVYcvcACYvMKuEvsaF3GDrFBTuLksclg2zgFPC SOXZjDCnGRu8TRnmlMExh5FzAyrGJUL04tKkst0jXTSyrKTM8oyU3MzNE1NDDTy00tLk5MT81 JTCrWS87P3cQIDAcGINjBOO+E/yFGSQ4mJVFetmOLI4T4kvJTKjMSizPii0pzUosPMcpwcChJ 8DIBw0tIsCg1PbUiLTMHGJgwaQkOHiUR3p+iQGne4oLE3OLMdIjUKUZdji87z7xkEmLJy89Ll RLn/QhSJABSlFGaBzcCFiWXGGWlhHkZgY4S4ilILcrNLEGVf8UozsGoJMz7H2QKT2ZeCdymV0 BHMAEdwRq3EOSIkkSElFQDo/QtruP8Kedf/KkzYs44ENhsafnDpSF7j/N6OV+DhYrqiX9PXri +8pfS667S/MvaynafDXRa49lfF7XPzs65tqNo+eqA94zyGl6786p/vKhuL1n0LVpgsUlrYJxS oEze1/UM/3beMla2qo45vmmjzba+rfIHrvwJ3xp16sf6Tp+t6vP9TRcVKrEUZyQaajEXFScCA LnIqM2NAgAA X-Env-Sender: yi.y.sun@linux.intel.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1487148772!76852937!4 X-Originating-IP: [134.134.136.24] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n X-StarScan-Received: X-StarScan-Version: 9.2.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23584 invoked from network); 15 Feb 2017 08:53:00 -0000 Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 15 Feb 2017 08:53:00 -0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2017 00:53:00 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.35,165,1484035200"; d="scan'208"; a="1094969611" Received: from vmmmba-s2600wft.bj.intel.com ([10.240.193.63]) by orsmga001.jf.intel.com with ESMTP; 15 Feb 2017 00:52:57 -0800 From: Yi Sun To: xen-devel@lists.xenproject.org Date: Wed, 15 Feb 2017 16:49:18 +0800 Message-Id: <1487148579-7243-4-git-send-email-yi.y.sun@linux.intel.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1487148579-7243-1-git-send-email-yi.y.sun@linux.intel.com> References: <1487148579-7243-1-git-send-email-yi.y.sun@linux.intel.com> Cc: kevin.tian@intel.com, wei.liu2@citrix.com, andrew.cooper3@citrix.com, dario.faggioli@citrix.com, he.chen@linux.intel.com, ian.jackson@eu.citrix.com, Yi Sun , mengxu@cis.upenn.edu, jbeulich@suse.com, chao.p.peng@linux.intel.com Subject: [Xen-devel] [PATCH v8 03/24] x86: refactor psr: implement main data structures. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP To construct an extendible framework, we need analyze PSR features and abstract the common things and feature specific things. Then, encapsulate them into different data structures. By analyzing PSR features, we can get below map. +------+------+------+ --------->| Dom0 | Dom1 | ... | | +------+------+------+ | | |Dom ID | cos_id of domain | V | +-----------------------------------------------------------------------------+ User --------->| PSR | Socket ID | +--------------+---------------+---------------+ | | | Socket0 Info | Socket 1 Info | ... | | | +--------------+---------------+---------------+ | | | cos_id=0 cos_id=1 ... | | | +-----------------------+-----------------------+-----------+ | | |->Ref : | ref 0 | ref 1 | ... | | | | +-----------------------+-----------------------+-----------+ | | | +-----------------------+-----------------------+-----------+ | | |->L3 CAT: | cos 0 | cos 1 | ... | | | | +-----------------------+-----------------------+-----------+ | | | +-----------------------+-----------------------+-----------+ | | |->L2 CAT: | cos 0 | cos 1 | ... | | | | +-----------------------+-----------------------+-----------+ | | | +-----------+-----------+-----------+-----------+-----------+ | | |->CDP : | cos0 code | cos0 data | cos1 code | cos1 data | ... | | | +-----------+-----------+-----------+-----------+-----------+ | +-----------------------------------------------------------------------------+ So, we need define a socket info data structure, 'struct psr_socket_info' to manage information per socket. It contains a reference count array according to COS ID and a feature list to manage all features enabled. Every entry of the reference count array is used to record how many domains are using the COS registers according to the COS ID. For example, L3 CAT and L2 CAT are enabled, Dom1 uses COS_ID=1 registers of both features to save CBM values, like below. +-------+-------+-------+-----+ | COS 0 | COS 1 | COS 2 | ... | +-------+-------+-------+-----+ L3 CAT | 0x7ff | 0x1ff | ... | ... | +-------+-------+-------+-----+ L2 CAT | 0xff | 0xff | ... | ... | +-------+-------+-------+-----+ If Dom2 has same CBM values, it can reuse these registers which COS_ID=1. That means, both Dom1 and Dom2 use same COS registers(ID=1) to save same L3/L2 values. So, the value ref[1] is 2 which means 2 domains are using COS_ID 1. To manage a feature, we need define a feature node data structure, 'struct feat_node', to manage feature's specific HW info, its callback functions (all feature's specific behaviors are encapsulated into these callback functions), and an array of all COS registers values of this feature. CDP is a special feature which uses two entries of the array for one COS ID. So, the number of CDP COS registers is the half of L3 CAT. E.g. L3 CAT has 16 COS registers, then CDP has 8 COS registers if it is enabled. CDP uses the COS registers array as below. +-----------+-----------+-----------+-----------+-----------+ CDP cos_reg_val[] index: | 0 | 1 | 2 | 3 | ... | +-----------+-----------+-----------+-----------+-----------+ value: | cos0 code | cos0 data | cos1 code | cos1 data | ... | +-----------+-----------+-----------+-----------+-----------+ For more details, please refer SDM and patches to implement 'get value' and 'set value'. Signed-off-by: Yi Sun Reviewed-by: Konrad Rzeszutek Wilk --- xen/arch/x86/psr.c | 108 ++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 107 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c index 96a8589..5acd9ca 100644 --- a/xen/arch/x86/psr.c +++ b/xen/arch/x86/psr.c @@ -13,16 +13,122 @@ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for * more details. */ -#include #include #include +#include +#include #include #include +/* + * Terminology: + * - CAT Cache Allocation Technology + * - CBM Capacity BitMasks + * - CDP Code and Data Prioritization + * - COS/CLOS Class of Service. Also mean COS registers. + * - COS_MAX Max number of COS for the feature (minus 1) + * - MSRs Machine Specific Registers + * - PSR Intel Platform Shared Resource + */ + #define PSR_CMT (1<<0) #define PSR_CAT (1<<1) #define PSR_CDP (1<<2) +/* + * Per SDM chapter 'Cache Allocation Technology: Cache Mask Configuration', + * the MSRs ranging from 0C90H through 0D0FH (inclusive), enables support for + * up to 128 L3 CAT Classes of Service. The COS_ID=[0,127]. + * + * The MSRs ranging from 0D10H through 0D4FH (inclusive), enables support for + * up to 64 L2 CAT COS. The COS_ID=[0,63]. + * + * So, the maximum COS register count of one feature is 128. + */ +#define MAX_COS_REG_CNT 128 + +/* + * PSR features are managed per socket. Below structure defines the members + * used to manage these features. + * feat_mask - Mask used to record features enabled on socket. There may be + * some features enabled at same time. + * nr_feat - Record how many features enabled. + * feat_list - A list used to manage all features enabled. + * cos_ref - A reference count array to record how many domains are using the + * COS_ID. + * Every entry of cos_ref corresponds to one COS ID. + * ref_lock - A lock to protect cos_ref. + */ +struct psr_socket_info { + /* + * It maps to values defined in 'enum psr_feat_type' below. Value in 'enum + * psr_feat_type' means the bit position. + * bit 0: L3 CAT + * bit 1: L3 CDP + * bit 2: L2 CAT + */ + unsigned int feat_mask; + unsigned int nr_feat; + struct list_head feat_list; + unsigned int cos_ref[MAX_COS_REG_CNT]; + spinlock_t ref_lock; +}; + +enum psr_feat_type { + PSR_SOCKET_L3_CAT = 0, + PSR_SOCKET_L3_CDP, + PSR_SOCKET_L2_CAT, +}; + +/* CAT/CDP HW info data structure. */ +struct psr_cat_hw_info { + unsigned int cbm_len; + unsigned int cos_max; +}; + +/* Encapsulate feature specific HW info here. */ +struct feat_hw_info { + union { + struct psr_cat_hw_info l3_cat_info; + }; +}; + +struct feat_node; + +/* + * This structure defines feature operation callback functions. Every feature + * enabled MUST implement such callback functions and register them to ops. + * + * Feature specific behaviors will be encapsulated into these callback + * functions. Then, the main flows will not be changed when introducing a new + * feature. + */ +struct feat_ops { + /* get_cos_max is used to get feature's cos_max. */ + unsigned int (*get_cos_max)(const struct feat_node *feat); +}; + +/* + * This structure represents one feature. + * feature - Which feature it is. + * feat_ops - Feature operation callback functions. + * info - Feature HW info. + * cos_reg_val - Array to store the values of COS registers. One entry stores + * the value of one COS register. + * For L3 CAT and L2 CAT, one entry corresponds to one COS_ID. + * For CDP, two entries correspond to one COS_ID. E.g. + * COS_ID=0 corresponds to cos_reg_val[0] (Data) and + * cos_reg_val[1] (Code). + * list - Feature list. + */ +struct feat_node { + enum psr_feat_type feature; + struct feat_ops ops; + struct feat_hw_info info; + uint64_t cos_reg_val[MAX_COS_REG_CNT]; + struct list_head list; +}; + struct psr_assoc { uint64_t val; uint64_t cos_mask;