Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2716695ybk; Mon, 18 May 2020 06:21:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxfq1fXDRJKLCrYQqm2s9J+1yHFM7FXsnWc6m2cqAPZ5o7kVFrVwcgt41gfdapqZX9bar3S X-Received: by 2002:aa7:dd84:: with SMTP id g4mr13986551edv.273.1589808117635; Mon, 18 May 2020 06:21:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589808117; cv=none; d=google.com; s=arc-20160816; b=Hculu4a6pVJGs3A2CY2RfSzjPEMEvAjOKdnugzkrsZoeEFpCvzUufGxxH6GBQ67kGV 8/87+lBJNEfMoLzUWC3GN0iJTNF6eowpksXp5jdA7G/fgDYHA4B1kAJlDkbhf31fhAci ISVv/jmV3PqWweuWJMlf+JYMGwWsnKHs6OlDQGDnR8wKdEWdN7y9EMLUlKa7F781i7py 8nmZSUocUqbQvbc4vpLwzjLQFfye1pgpT2cFfUHFkzI/S81P8NoJRD2vR/yh2KQJnVhc 0Ba0b3tYAUYnGUlgZigB0sP4Mn+2mQB4yLzldlOd3k7y02oo30wrem5Y29Cs3rV/Vpfx 29xA== 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=cK7Xsm0pGpjo3CIrDf5XSKqCRI+t2OrEVgadTTQacPs=; b=avuN4Dk4b36DbBgtWHRcUhPjpK3/H16WCbwjMg4CgeSi8Qjlqha4WxZF+gOVyvuPBi JUqhVmHd3i9htMzswCWnr5+/KYoQfGBlfo7HFIDgyhLjGulvru7RY+k1wb5U9TP68Ghf 9z8RaXpUzOcnETGRhYCW0/trLjj4Je7fhuPdhfasgyy+kQSKnibFWgfDIaBGquwsWyVI dINync6W4aqO3OR4j9nx63M3zH37gm0uyEHY3rfo7VpeuUvbZcQtNRbrvLeoWHzCh2jh UkoT33r4Z3AtTCIJoyfYrJp57KHEalvJAlDMvVqeyENyya14HC4RqvyBHhQT8xT1KQNH 4nmw== 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 b102si1844310edf.194.2020.05.18.06.21.33; Mon, 18 May 2020 06:21:57 -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 S1728019AbgERNTx (ORCPT + 99 others); Mon, 18 May 2020 09:19:53 -0400 Received: from foss.arm.com ([217.140.110.172]:40450 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727957AbgERNTq (ORCPT ); Mon, 18 May 2020 09:19:46 -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 2FCC813FD; Mon, 18 May 2020 06:19:45 -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 D3A6F3F305; Mon, 18 May 2020 06:19:43 -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 v3 07/10] x86/resctrl: Add arch_needs_linear to explain AMD/Intel MBA difference Date: Mon, 18 May 2020 14:19:20 +0100 Message-Id: <20200518131924.7741-8-james.morse@arm.com> X-Mailer: git-send-email 2.19.1 In-Reply-To: <20200518131924.7741-1-james.morse@arm.com> References: <20200518131924.7741-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 e1fed3928b59..c6b73b0ee070 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 934c8fb8a64a..e3bcd77add2b 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 dd51e23e346b..0b288b6fefd9 100644 --- a/arch/x86/kernel/cpu/resctrl/internal.h +++ b/arch/x86/kernel/cpu/resctrl/internal.h @@ -370,6 +370,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 @@ -378,6 +379,7 @@ struct rdt_membw { u32 min_bw; u32 bw_gran; u32 delay_linear; + bool arch_needs_linear; bool mba_sc; u32 *mb_map; }; -- 2.19.1