Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2690932imm; Fri, 24 Aug 2018 03:47:37 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYWnJA2e2SX4wEvrmt5Oj2gR+YKiHeUBXC0VuQO+Rdw0hcZl1nYpRdGxZKHgRssgfdfuhHn X-Received: by 2002:a65:65c6:: with SMTP id y6-v6mr1191313pgv.436.1535107657462; Fri, 24 Aug 2018 03:47:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535107657; cv=none; d=google.com; s=arc-20160816; b=cWPKVhevw0oCiM14vxvqT76DuW+0kbggm67wvsFWc4YXyRmRFFCRu3I7Ol47FwiJBJ +o9FSxFgrsZPhcqpZcSUdMCCSZnAoFvy6rqw4xQum3u2y2NdZxVVqifkSMMg8V7is+nP VA2xxQycASuv/PGE4V88UhlXJjj1b4XiMRR86maURcDj2JQ4Fc0nF4zRiGotq7qkm178 Owb8cYruzPres6iF0kTjoKiBFRbaVJVjade6r3RkFUMhDcIHnvFYpayTnpmDk4EYQJHu PN/8OQH91qnUhSUbj2+gEilzOtGFgMEqJyD1GocKuoABfYm3tqJ7tegf/Khb8KPQDHBJ yJ1w== 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 :arc-authentication-results; bh=wzq6u0GP0Lq3glayKAY5JyG4VWVPexFw4dngmLexrLI=; b=Ni1I71Dw8moEezhlJTLdYY6AvNnfAH2x2lnOWHFF1O3f5qi6DIQJ5fP7QU1wXAsaO1 Mhk3XysqiV9rmpmHv/EOkD+xc5FEMypgxt7Ge5lUCtAANLdO622o8AbvIGtWeGc56MMI XbTzT/GTks9V1/wpFC54VIK/+KcpluzzuOFyxQYHzKmj3qYbTEQUbV6jbn7tYNWhpwjs VPWLDaPWEa16gTxr5uY7cBwhTVlalL/pCLy9Mb88YTNl85CMdVFitw7NgnchYtuYQEyR g1viDIQfjdCorBQSeKyMQ3GC5/W8O2tlRaxpliPmojGmStwZy9IQp3iM7P2C9Mj1vNWv OORg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y67-v6si7028801pfa.47.2018.08.24.03.47.22; Fri, 24 Aug 2018 03:47:37 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726786AbeHXOTz (ORCPT + 99 others); Fri, 24 Aug 2018 10:19:55 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:55412 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726330AbeHXOTz (ORCPT ); Fri, 24 Aug 2018 10:19:55 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B722215A2; Fri, 24 Aug 2018 03:45:50 -0700 (PDT) Received: from melchizedek.Emea.Arm.com (melchizedek.emea.arm.com [10.4.12.81]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 1A2E63F5A0; Fri, 24 Aug 2018 03:45:48 -0700 (PDT) From: James Morse To: linux-kernel@vger.kernel.org Cc: x86@kernel.org, Thomas Gleixner , Fenghua Yu , Tony Luck , Ingo Molnar , H Peter Anvin , Reinette Chatre , Vikas Shivappa Subject: [RFC PATCH 00/20] x86/intel_rdt: Start abstraction for a second arch Date: Fri, 24 Aug 2018 11:44:59 +0100 Message-Id: <20180824104519.11203-1-james.morse@arm.com> X-Mailer: git-send-email 2.18.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi folks, ARM have some upcoming CPU features that are similar to Intel RDT. Resctrl is the defacto ABI for this sort of thing, but it lives under arch/x86. To get existing software working, we need to make resctrl work with arm64. This series is the first chunk of that. The aim is to move the filesystem/ABI parts into /fs/resctrl, and implement a second arch backend. What are the ARM features? Future ARM SoCs may have a feature called MPAM: Memory Partitioning and Monitoring. This is an umbrella term like RDT, and covers a range of controls (like CAT) and monitors (like MBM, CMT). This series is almost all about CDP. MPAM has equivalent functionality, but it doesn't need enabling, and doesn't affect the available closids. (I'll try and use Intel terms). MPAM expects the equivalent to IA32_PRQ_MSR to be configured with an Instruction closid and a Data closid. These are the same for no-CDP, and different otherwise. There is no need for them to be adjacent. To avoid emulating CDP in arm64's arch code, this series moves all the ABI parts of the CDP behaviour, (half the closid-space, each having two configurations) into the filesystem parts of resctrl. These will eventually be moved to /fs/. MPAMs control and monitor configuration is all memory mapped, the base addresses are discovered via firmware tables, so we won't have a table of possible resources that just need alloc_enabling. Is this it? No... there are another two series of a similar size that abstract the MBM/CMT overflow threads and avoid 'fs' code accessing things that have moved into the 'hw' arch specific struct. I'm after feedback on the general approach taken here, bugs, as there are certainly subtleties I've missed, and any strong-opinions on what should be arch-specific, and what shouldn't. This series is based on v4.18, and can be retrieved from: git://linux-arm.org/linux-jm.git -b mpam/resctrl_rework/rfc_1 Thanks, James Morse (20): x86/intel_rdt: Split struct rdt_resource x86/intel_rdt: Split struct rdt_domain x86/intel_rdt: Group staged configuration into a separate struct x86/intel_rdt: Add closid to the staged config x86/intel_rdt: make update_domains() learn the affected closids x86/intel_rdt: Add a helper to read a closid's configuration for show_doms() x86/intel_rdt: Expose update_domains() as an arch helper x86/intel_rdt: Make cdp enable/disable global x86/intel_rdt: Track the actual number of closids separately x86/intel_rdt: Let resctrl change the resources's num_closid x86/intel_rdt: Pass in the code/data/both configuration value when parsing x86/intel_rdt: Correct the closid when staging configuration changes x86/intel_rdt: Allow different CODE/DATA configurations to be staged x86/intel_rdt: Add a separate resource list for resctrl x86/intel_rdt: Walk the resctrl schema list instead of the arch's resource list x86/intel_rdt: Move the schemata names into struct resctrl_schema x86/intel_rdt: Stop using Lx CODE/DATA resources x86/intel_rdt: Remove the CODE/DATA illusionary caches x86/intel_rdt: Kill off alloc_enabled x86/intel_rdt: Merge cdp enable/disable calls arch/x86/kernel/cpu/intel_rdt.c | 298 +++++++------------- arch/x86/kernel/cpu/intel_rdt.h | 161 ++++------- arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 142 +++++++--- arch/x86/kernel/cpu/intel_rdt_monitor.c | 78 ++--- arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 216 +++++++++----- include/linux/resctrl.h | 166 +++++++++++ 6 files changed, 621 insertions(+), 440 deletions(-) create mode 100644 include/linux/resctrl.h -- 2.18.0