linux-kernel - Re: [PATCH 1/7] x86/cpufeatures: Add support for L3 Smart Data Cache Injection Allocation Enforcement

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d2083424-409a-4b41-8996-d8ff9f51db2c@intel.com>
Date: Fri, 13 Sep 2024 13:44:45 -0700
From: Reinette Chatre <reinette.chatre@...el.com>
To: Babu Moger <babu.moger@....com>, <corbet@....net>, <tglx@...utronix.de>,
	<mingo@...hat.com>, <bp@...en8.de>, <dave.hansen@...ux.intel.com>,
	<x86@...nel.org>
CC: <fenghua.yu@...el.com>, <hpa@...or.com>, <paulmck@...nel.org>,
	<thuth@...hat.com>, <xiongwei.song@...driver.com>, <ardb@...nel.org>,
	<pawan.kumar.gupta@...ux.intel.com>, <daniel.sneddon@...ux.intel.com>,
	<sandipan.das@....com>, <kai.huang@...el.com>, <peterz@...radead.org>,
	<kan.liang@...ux.intel.com>, <pbonzini@...hat.com>, <xin3.li@...el.com>,
	<ebiggers@...gle.com>, <alexandre.chartre@...cle.com>, <perry.yuan@....com>,
	<tan.shaopeng@...itsu.com>, <james.morse@....com>, <tony.luck@...el.com>,
	<maciej.wieczor-retman@...el.com>, <linux-doc@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <peternewman@...gle.com>,
	<eranian@...gle.com>
Subject: Re: [PATCH 1/7] x86/cpufeatures: Add support for L3 Smart Data Cache
 Injection Allocation Enforcement

Hi Babu,

On 8/16/24 9:16 AM, Babu Moger wrote:
> Smart Data Cache Injection (SDCI) is a mechanism that enables direct
> insertion of data from I/O devices into the L3 cache. By directly caching
> data from I/O devices rather than first storing the I/O data in DRAM,
> SDCI reduces demands on DRAM bandwidth and reduces latency to the processor
> consuming the I/O data.
> 
> The SDCIAE (SDCI Allocation Enforcement) PQE feature allows system software
> to limit the portion of the L3 cache used for SDCI.
> 
> When enabled, SDCIAE forces all SDCI lines to be placed into the L3 cache
> partitions identified by the highest-supported L3_MASK_n register where n
> maximum supported CLOSID.

"where n maximum supported CLOSID" -> "where n is the maximum supported CLOSID" ?

> 
> Add CPUID feature bit that can be used to configure SDCIAE.
> 
> The feature details are documented in APM listed below [1].
> [1] AMD64 Architecture Programmer's Manual Volume 2: System Programming
> Publication # 24593 Revision 3.41 section 19.4.7 L3 Smart Data Cache
> Injection Allocation Enforcement (SDCIAE)
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
> Signed-off-by: Babu Moger <babu.moger@....com>
> ---
>   arch/x86/include/asm/cpufeatures.h | 1 +
>   arch/x86/kernel/cpu/cpuid-deps.c   | 1 +
>   arch/x86/kernel/cpu/scattered.c    | 1 +
>   3 files changed, 3 insertions(+)
> 
> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index dd4682857c12..5ca39431d423 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -473,6 +473,7 @@
>   #define X86_FEATURE_CLEAR_BHB_HW	(21*32+ 3) /* BHI_DIS_S HW control enabled */
>   #define X86_FEATURE_CLEAR_BHB_LOOP_ON_VMEXIT (21*32+ 4) /* Clear branch history at vmexit using SW loop */
>   #define X86_FEATURE_FAST_CPPC		(21*32 + 5) /* AMD Fast CPPC */
> +#define X86_FEATURE_SDCIAE		(21*32 + 6) /* "" L3 Smart Data Cache Injection Allocation Enforcement */
>   
>   /*
>    * BUG word(s)
> diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
> index b7d9f530ae16..1ef42cc4cc75 100644
> --- a/arch/x86/kernel/cpu/cpuid-deps.c
> +++ b/arch/x86/kernel/cpu/cpuid-deps.c
> @@ -70,6 +70,7 @@ static const struct cpuid_dep cpuid_deps[] = {
>   	{ X86_FEATURE_CQM_MBM_LOCAL,		X86_FEATURE_CQM_LLC   },
>   	{ X86_FEATURE_BMEC,			X86_FEATURE_CQM_MBM_TOTAL   },
>   	{ X86_FEATURE_BMEC,			X86_FEATURE_CQM_MBM_LOCAL   },
> +	{ X86_FEATURE_SDCIAE,			X86_FEATURE_RDT_A     },

The need for this dependency is not clear to me. If there was a dependency
then I would have expected it to be X86_FEATURE_CAT_L3 but we have not
previously needed to do this. For example, X86_FEATURE_CDP_L3 does not depend
on X86_FEATURE_CAT_L3 and in turn X86_FEATURE_CAT_L3 does not depend on
X86_FEATURE_RDT_A. Could you please elaborate why this is needed?

>   	{ X86_FEATURE_AVX512_BF16,		X86_FEATURE_AVX512VL  },
>   	{ X86_FEATURE_AVX512_FP16,		X86_FEATURE_AVX512BW  },
>   	{ X86_FEATURE_ENQCMD,			X86_FEATURE_XSAVES    },
> diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
> index c84c30188fdf..88f00575c9ff 100644
> --- a/arch/x86/kernel/cpu/scattered.c
> +++ b/arch/x86/kernel/cpu/scattered.c
> @@ -49,6 +49,7 @@ static const struct cpuid_bit cpuid_bits[] = {
>   	{ X86_FEATURE_MBA,		CPUID_EBX,  6, 0x80000008, 0 },
>   	{ X86_FEATURE_SMBA,		CPUID_EBX,  2, 0x80000020, 0 },
>   	{ X86_FEATURE_BMEC,		CPUID_EBX,  3, 0x80000020, 0 },
> +	{ X86_FEATURE_SDCIAE,		CPUID_EBX,  6, 0x80000020, 0 },
>   	{ X86_FEATURE_PERFMON_V2,	CPUID_EAX,  0, 0x80000022, 0 },
>   	{ X86_FEATURE_AMD_LBR_V2,	CPUID_EAX,  1, 0x80000022, 0 },
>   	{ X86_FEATURE_AMD_LBR_PMC_FREEZE,	CPUID_EAX,  2, 0x80000022, 0 },

Reinette