Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2058681ybz; Thu, 30 Apr 2020 10:07:14 -0700 (PDT) X-Google-Smtp-Source: APiQypKtlFKY2tbaI6FrBbU74uVOq3nePVv4VjsFFClQmMsD8PDNgftaCxjqoNdirf40tE2KTRSi X-Received: by 2002:aa7:d306:: with SMTP id p6mr3559396edq.35.1588266434249; Thu, 30 Apr 2020 10:07:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588266434; cv=none; d=google.com; s=arc-20160816; b=dET9AAOyxjEZcgWi4nGTjO1DOn6FRc2peAfOeRg9tjhdeovbSxR1F54/8tdhjKEgIP uiJtoBzmSP+FZk8TZxoJAxa+88++WZ6IoVoZXJbg8zS4vKrnxW3Ru2dqvBVi+X7IK1SW pnzZnagHMZmOwi0AN4veUgPCvUcIUqxAKugYjQJNu1m/P4fDQcvGZl2s1QAxqC/o81SN ctxKo/ZQrCtWlU+8txH+Y/ADsMGFaDUjC69Aij4baSwCTQCZk7dOds/PuCOr87POh2Az Nt90DfxhWA7trjrXGJAvZ1ZLF3ZO75UgfWOcFpToI4bUKyN6XpaxgVADSiKmiGsBUB/U ojkw== 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:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=Fvqfej28iyt0LZuAUNTX+BJejh1wli5i4aair5bDZoo=; b=uamtampzI/ZfnhBp84Y8zoQJJGJpYFowPYPtMFKbZ9tTHEDtDeadAzGNoMiLElab4s pXac0Gn2nqvYi1x70y52qo0vvLnWfBUr8bpTJuQfFP0nCofkOIFRPuWbNBVUwm9ZjL0a azKu2W0rKvSc+UgVT773gN7u+E2Kd/J5sn4N5ixgpqxi3cC+Wl4w0NgKTyLzg0/iOOB2 xq95Jw5cfL0Wn5kmyck6YEIdwEFQHT2Zfeu6diG+p7aPWRedTui4p2dmqQZ2UuH3oakH nmOPVhd2r0qm6nZ0nLDrtGiMNUF1pwTBu8qGqZLEjjbc2DcoudDNMBcWDxXUzZC4MZ+P VnGw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m4si120421ejd.315.2020.04.30.10.06.51; Thu, 30 Apr 2020 10:07:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727878AbgD3REh (ORCPT + 99 others); Thu, 30 Apr 2020 13:04:37 -0400 Received: from foss.arm.com ([217.140.110.172]:59204 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727853AbgD3REe (ORCPT ); Thu, 30 Apr 2020 13:04:34 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F1DD2106F; Thu, 30 Apr 2020 10:04:33 -0700 (PDT) Received: from melchizedek.cambridge.arm.com (melchizedek.cambridge.arm.com [10.1.196.50]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A33E23F73D; Thu, 30 Apr 2020 10:04:32 -0700 (PDT) From: James Morse To: x86@kernel.org, linux-kernel@vger.kernel.org Cc: Fenghua Yu , Reinette Chatre , Thomas Gleixner , Ingo Molnar , Borislav Petkov , H Peter Anvin , Babu Moger , James Morse Subject: [PATCH v2 07/10] x86/resctrl: Add arch_needs_linear to explain AMD/Intel MBA difference Date: Thu, 30 Apr 2020 18:03:57 +0100 Message-Id: <20200430170400.21501-8-james.morse@arm.com> X-Mailer: git-send-email 2.19.1 In-Reply-To: <20200430170400.21501-1-james.morse@arm.com> References: <20200430170400.21501-1-james.morse@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The configuration values user-space provides to the resctrl filesystem are ABI. To make this work on another architecture we want to move all the ABI bits out of /arch/x86 and under /fs. To do this, the differences between AMD and Intel CPUs needs to be explained to resctrl via resource properties, instead of function pointers that let the arch code accept subtly different values on different platforms/architectures. For MBA, Intel CPUs reject configuration attempts for non-linear resources, whereas AMD ignore this field as its MBA resource is never linear. To merge the parse/validate functions we need to explain this difference. Add arch_needs_linear to indicate the arch code needs the linear property to be true to configure this resource. AMD can set this and delay_linear to false. Intel can set arch_needs_linear to true to keep the existing "No support for non-linear MB domains" error message for affected platforms. CC: Babu Moger Signed-off-by: James Morse Reviewed-by: Reinette Chatre --- An alternative to this is for Intel non-linear MBA resources to clear alloc_capable as they can't be configured anyway. --- arch/x86/kernel/cpu/resctrl/core.c | 3 +++ arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 8 +++++++- arch/x86/kernel/cpu/resctrl/internal.h | 2 ++ 3 files changed, 12 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c index 9048f421af84..40186c54b05d 100644 --- a/arch/x86/kernel/cpu/resctrl/core.c +++ b/arch/x86/kernel/cpu/resctrl/core.c @@ -260,6 +260,7 @@ static bool __get_mem_config_intel(struct rdt_resource *r) r->num_closid = edx.split.cos_max + 1; max_delay = eax.split.max_delay + 1; r->default_ctrl = MAX_MBA_BW; + r->membw.arch_needs_linear = true; if (ecx & MBA_IS_LINEAR) { r->membw.delay_linear = true; r->membw.min_bw = MAX_MBA_BW - max_delay; @@ -267,6 +268,7 @@ static bool __get_mem_config_intel(struct rdt_resource *r) } else { if (!rdt_get_mb_table(r)) return false; + r->membw.arch_needs_linear = false; } r->data_width = 3; @@ -288,6 +290,7 @@ static bool __rdt_get_mem_config_amd(struct rdt_resource *r) /* AMD does not use delay */ r->membw.delay_linear = false; + r->membw.arch_needs_linear = false; r->membw.min_bw = 0; r->membw.bw_gran = 1; diff --git a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c index 055c8613b531..db8e6c0cadb1 100644 --- a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c +++ b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c @@ -33,6 +33,12 @@ static bool bw_validate_amd(char *buf, unsigned long *data, unsigned long bw; int ret; + /* temporary: always false on AMD */ + if (!r->membw.delay_linear && r->membw.arch_needs_linear) { + rdt_last_cmd_puts("No support for non-linear MB domains\n"); + return false; + } + ret = kstrtoul(buf, 10, &bw); if (ret) { rdt_last_cmd_printf("Non-decimal digit in MB value %s\n", buf); @@ -82,7 +88,7 @@ static bool bw_validate(char *buf, unsigned long *data, struct rdt_resource *r) /* * Only linear delay values is supported for current Intel SKUs. */ - if (!r->membw.delay_linear) { + if (!r->membw.delay_linear && r->membw.arch_needs_linear) { rdt_last_cmd_puts("No support for non-linear MB domains\n"); return false; } diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h index 1ff6718307cf..215be9957acf 100644 --- a/arch/x86/kernel/cpu/resctrl/internal.h +++ b/arch/x86/kernel/cpu/resctrl/internal.h @@ -363,6 +363,7 @@ struct rdt_cache { * struct rdt_membw - Memory bandwidth allocation related data * @min_bw: Minimum memory bandwidth percentage user can request * @bw_gran: Granularity at which the memory bandwidth is allocated + * @arch_needs_linear: True if we can't configure non-linear resources * @delay_linear: True if memory B/W delay is in linear scale * @mba_sc: True if MBA software controller(mba_sc) is enabled * @mb_map: Mapping of memory B/W percentage to memory B/W delay @@ -371,6 +372,7 @@ struct rdt_membw { u32 min_bw; u32 bw_gran; u32 delay_linear; + bool arch_needs_linear; bool mba_sc; u32 *mb_map; }; -- 2.26.1