Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp4451674ybh; Tue, 6 Aug 2019 11:55:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqz8Gk2HqgFCtTDBYjur6QVWecTHpW50oALQZrCBM0oq2yXAZYewV0U0orvGLi3qd9gtS4/6 X-Received: by 2002:a62:e801:: with SMTP id c1mr5235761pfi.41.1565117701832; Tue, 06 Aug 2019 11:55:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565117701; cv=none; d=google.com; s=arc-20160816; b=iRSnHqCVotobAjOHu2uphH6GmlQOHMi/0ER2ViqFHLUQNjWIMUaWmLpZN/PsIzukfa EwUqd+zhyjAjplwygemKijSnjRAnkbgmNOv2eWnSbhqn7g2oGxpa0sXwVLp7e5Zwz0RC LlG+Fmadvt9qVcPanjtEuKGslYA/cLM26llB0vxJ4HgUfMb1LS2coEmQ2HyYmkvCFSGX 086RJzVe8xuD20EonyJnRSOFgY9aJluSTrTNfNlAYsDpc2AtCg2Jiv2ewy1ntSPEG0Oa nipXz3yAHp0c/czOzVmSoRRUQFZMF6riS21EoS7s79oW/weP9BnHW3GoFhXzw/iB6INK PZxQ== 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=1B30HIOFp2arn3IujpQ2qgLn5lGVjctrMuvlfoQCyck=; b=p/x875BD2VMmeGRP6d02chGOEmBjiiwGyLgnE6JBLwJVXNyaVWgSGfZrz3aEoCU7uI 2FhiIcbGtku7trSn9Rktgqmsnmir5HW+fFhmMgRfmE61DPh+dNJab34BWxtZ4oyGfsxT lRukMjPKUUhih3oQ3sTN8Kq6sViSMoErihA5Arf9GAuGtW4687Ta3RIwGF31TIAxS4HV 29uVwtyVnlD0iAlyf0WRGgDq20+gOjuIpz/wVCvRpti6Rv56RBKuKnzOir4VSe9U6BZb B3Ec83QSRD3IDl0SzVZSTFUoLbCe4UEAHQe/t47audv8tkAYbL6/80vBJ1crIn5azk+2 LDLQ== 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 e13si50920473pfl.279.2019.08.06.11.54.46; Tue, 06 Aug 2019 11:55:01 -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 S1726085AbfHFSxn (ORCPT + 99 others); Tue, 6 Aug 2019 14:53:43 -0400 Received: from mga06.intel.com ([134.134.136.31]:40663 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725973AbfHFSxn (ORCPT ); Tue, 6 Aug 2019 14:53:43 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Aug 2019 11:53:43 -0700 X-IronPort-AV: E=Sophos;i="5.64,353,1559545200"; d="scan'208";a="325721927" Received: from rchatre-mobl.amr.corp.intel.com (HELO [10.24.14.91]) ([10.24.14.91]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/AES256-SHA; 06 Aug 2019 11:53:42 -0700 Subject: Re: [PATCH V2 01/10] x86/CPU: Expose if cache is inclusive of lower level caches To: Borislav Petkov Cc: tglx@linutronix.de, fenghua.yu@intel.com, tony.luck@intel.com, kuo-lang.tseng@intel.com, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org References: <6c78593207224014d6a9d43698a3d1a0b3ccf2b6.1564504901.git.reinette.chatre@intel.com> <20190802180352.GE30661@zn.tnic> <20190803094423.GA2100@zn.tnic> <122b005a-46b1-2b1e-45a8-7f92a5dba2d9@intel.com> <20190806155716.GE25897@zn.tnic> <151002be-33e6-20d6-7699-bc9be7e51f33@intel.com> <20190806173300.GF25897@zn.tnic> <20190806183333.GA4698@zn.tnic> From: Reinette Chatre Message-ID: Date: Tue, 6 Aug 2019 11:53:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190806183333.GA4698@zn.tnic> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Borislav, On 8/6/2019 11:33 AM, Borislav Petkov wrote: > On Tue, Aug 06, 2019 at 11:13:22AM -0700, Reinette Chatre wrote: >> Some platforms being enabled in this round have SKUs with inclusive >> cache and also SKUs with non-inclusive cache. The non-inclusive cache >> SKUs do not support cache pseudo-locking and cannot be made to support >> cache pseudo-locking with software changes. Needing to know if cache is >> inclusive or not will thus remain a requirement to distinguish between >> these different SKUs. Supporting cache pseudo-locking on platforms with >> non inclusive cache will require new hardware features. > > Is there another way/CPUID bit or whatever to tell us whether the > platform supports cache pseudo-locking or is the cache inclusivity the > only one? Unfortunately there are no hardware bits that software can use to determine if cache pseudo-locking is supported. The way software currently determines if cache pseudo-locking is supported is through initialization of the hardware prefetch disable bits. Cache pseudo-locking requires the hardware prefetch bits to be disabled (during the locking flow only), those cannot be discovered either and thus software hardcodes the hardware prefetch disable bits only for those platforms that support cache pseudo-locking. What you will see in the code is this: int rdtgroup_locksetup_enter(struct rdtgroup *rdtgrp) { ... prefetch_disable_bits = get_prefetch_disable_bits(); if (prefetch_disable_bits == 0) { rdt_last_cmd_puts("Pseudo-locking not supported\n"); return -EINVAL; } ... } In get_prefetch_disable_bits() the platforms that support cache pseudo-locking are hardcoded as part of configuring the hardware prefetch disable bits to use. The current problem is that an upcoming platform has this difference between SKUs so a single platform-wide decision is not sufficient. Reinette