Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1232589imm; Fri, 14 Sep 2018 13:38:49 -0700 (PDT) X-Google-Smtp-Source: ANB0VdavIWVEDjzpwfXueEp8LGyd1+EB8iyXERyEWvEeKWo0A3uAJlkTh+yr+5iHS+GwwvsgJ1wE X-Received: by 2002:a17:902:e004:: with SMTP id ca4-v6mr13462127plb.252.1536957529006; Fri, 14 Sep 2018 13:38:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536957528; cv=none; d=google.com; s=arc-20160816; b=ayAmgGsptdgH7Eps+CcfLmZ8V87NLQJptJL2aIgHN0frIPuBqrPtLiNZ+NnuK8eAyA Nwz2B+2xUY0g/T+es1GCt15epDuxQoRN2nI3f5NkM70IQd7SpGU6Ik4XGbPEhD8Tg3MJ TUw80rnLZ8lgcYLIs+gYxjlLFEIteTk9UZwoc70HQw4DCZDvwEnkyUAGX/Xs3pFFF3DO +q87ty2DcAb+CUwu9Q8A/TFwziOFhI5SF7MzTEkaKDgiIvOjL7BMqdLl8M0fwz321bgw KS+5YnqeFL380rZSLb8f+gqeDa1Q9vLZzOzNliO4S2sVSFqUrY/o0EkkfQSn2K6Pw0UY g5hQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=NSYZRbRX8G7skI17fJDzYgrFK79t9n5mV2BO00uIUVQ=; b=lzwqLVRrfVSp+d7mkZQLVolp3WOAR6pOpXpIIu5d/uHvL/sskQVWWIkXIN5Q7IMck7 YEj2mjJv4dZUW5J9Yt4UYcHMXEhd7OjD21ItdtDpmW6/ookUi2/b6rlj7BKppEcqwYjd 5zVXqn/Nqt9+sfBv6s7t3aMx/Sua8pRQNdlt/KC1svzb3890iORCWMFpcD6UMgGvl0Mv cebRtI1BcmmIBc0NgtxaPNTBjS4DPimtKt7dGJ/++rfqICHnLp831J8m3l+8B3aBNH2v PfUF+igLV1CPtoVRNJ2HnmL003UxB1tE2gUBlIkHHQW1cziHIT2LGtdgIUTi3ycPi7OK LxVA== 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 e12-v6si7559040pls.372.2018.09.14.13.38.34; Fri, 14 Sep 2018 13:38:48 -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 S1728208AbeIOBwt (ORCPT + 99 others); Fri, 14 Sep 2018 21:52:49 -0400 Received: from mga05.intel.com ([192.55.52.43]:60388 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727416AbeIOBvv (ORCPT ); Fri, 14 Sep 2018 21:51:51 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2018 13:35:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,374,1531810800"; d="scan'208";a="263593790" Received: from romley-ivt3.sc.intel.com ([172.25.110.60]) by fmsmga006.fm.intel.com with ESMTP; 14 Sep 2018 13:35:44 -0700 From: Fenghua Yu To: "Thomas Gleixner" , "Ingo Molnar" , "H Peter Anvin" , "Tony Luck" Cc: "Chatre, Reinette" , "Xiaochen Shen" , "Chen Yu" , "linux-kernel" , "x86" , "Fenghua Yu" Subject: [PATCH 0/9] x86/intel_rdt: MBA integration fixes Date: Fri, 14 Sep 2018 13:32:00 -0700 Message-Id: <1536957129-70380-1-git-send-email-fenghua.yu@intel.com> X-Mailer: git-send-email 2.5.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Chen Yu reported an issue where reading the resctrl "size" file results in a divide-by-zero issue on a system with a MBA resource. Further investigation revealed more issues where the recent RDT features are not well integrated with the MBA resource handling. This series consists out of: - One helper function in support of fixes that need to know the number of supported CLOSIDs on the system (the minimum of all CLOSIDs of all resources). - The fix to the issue reported by Chen Yu - now reading a resource group's "size" file will show a MB resource's allocation as its size. - A fix from Xiaochen Shen to the MB parsing callback that was never changed to accept a new parameter format. - Functions that iterate over the number of CLOSIDs need to take care whether it is using a particular resource's supported CLOSIDs or the number of CLOSIDs supported by the system. This was done incorrectly in a few places and fixed here. - When a new resource group is created it is intended to be configured with sane defaults. This new feature blindly assumed that the resource group only consists out of cache resources - make this explicit to not cause invalid register writes on a system with MBA resources. - The new "exclusive" mode assumes that all resources support a CBM, while a MBA resource does not. Since the MBA resource allocations cannot be done in a way to specify whether allocations can overlap or not the "exclusive" mode of a resource group will only apply to the cache resources within the group, if only a MBA resource is present then "exclusive" mode will not be allowed. Reinette Chatre (8): x86/intel_rdt: Fix size reporting of MBA resource x86/intel_rdt: Global closid helper to support future fixes x86/intel_rdt: Fix invalid mode warning when x86/intel_rdt: Fix unchecked MSR access x86/intel_rdt: Do not allow pseudo-locking of MBA resource x86/intel_rdt: Fix incorrect loop end condition x86/intel_rdt: Fix exclusive mode handling of MBA resource x86/intel_rdt: Fix incorrect loop end condition Xiaochen Shen (1): x86/intel_rdt: Fix MBA parsing callback arch/x86/kernel/cpu/intel_rdt.h | 3 +- arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 30 +++++++----- arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 53 +++++++++++++++++---- 3 files changed, 64 insertions(+), 22 deletions(-) -- 2.19.0