linux-kernel - Re: [RFC PATCH v2 4/8] x86: ibs: In-kernel IBS driver for memory access profiling

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: <531fea9f-a9c1-40d3-89a3-7b90d6b3c1d4@amd.com>
Date: Mon, 6 Oct 2025 09:58:13 +0530
From: Bharata B Rao <bharata@....com>
To: Jonathan Cameron <jonathan.cameron@...wei.com>
CC: <linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
	<dave.hansen@...el.com>, <gourry@...rry.net>, <hannes@...xchg.org>,
	<mgorman@...hsingularity.net>, <mingo@...hat.com>, <peterz@...radead.org>,
	<raghavendra.kt@....com>, <riel@...riel.com>, <rientjes@...gle.com>,
	<sj@...nel.org>, <weixugc@...gle.com>, <willy@...radead.org>,
	<ying.huang@...ux.alibaba.com>, <ziy@...dia.com>, <dave@...olabs.net>,
	<nifan.cxl@...il.com>, <xuezhengchu@...wei.com>, <yiannis@...corp.com>,
	<akpm@...ux-foundation.org>, <david@...hat.com>, <byungchul@...com>,
	<kinseyho@...gle.com>, <joshua.hahnjy@...il.com>, <yuanchu@...gle.com>,
	<balbirs@...dia.com>, <alok.rathore@...sung.com>
Subject: Re: [RFC PATCH v2 4/8] x86: ibs: In-kernel IBS driver for memory
 access profiling

On 03-Oct-25 5:49 PM, Jonathan Cameron wrote:
> On Wed, 10 Sep 2025 20:16:49 +0530
> Bharata B Rao <bharata@....com> wrote:
>>  
>> @@ -1756,6 +1758,15 @@ static __init int amd_ibs_init(void)
>>  {
>>  	u32 caps;
>>  
>> +	/*
>> +	 * TODO: Find a clean way to disable perf IBS so that IBS
>> +	 * can be used for memory access profiling.
> 
> Agreed on this being a key thing.  This applies to quite a few
> other sources of data so finding a generally acceptable solution to this
> would be great.  Davidlohr mentioned on the CXL sync that he has
> something tackling this for the CHMU driver around this.

Okay, will wait to check that.

> 
> 
>> +	 */
>> +	if (arch_hw_access_profiling) {
>> +		pr_info("IBS isn't available for perf use\n");
>> +		return 0;
>> +	}
>> +
>>  	caps = __get_ibs_caps();
>>  	if (!caps)
>>  		return -ENODEV;	/* ibs not supported by the cpu */
> 
>> diff --git a/arch/x86/mm/ibs.c b/arch/x86/mm/ibs.c
>> new file mode 100644
>> index 000000000000..6669710dd35b
>> --- /dev/null
>> +++ b/arch/x86/mm/ibs.c
>> @@ -0,0 +1,311 @@
> 
> ...
> 
>> +
>> +static int ibs_pop_sample(struct ibs_sample *s)
>> +{
>> +	struct ibs_sample_pcpu *ibs_pcpu = raw_cpu_ptr(ibs_s);
>> +
>> +	int next = ibs_pcpu->tail + 1;
>> +
>> +	if (ibs_pcpu->head == ibs_pcpu->tail)
>> +		return 0;
>> +
>> +	if (next >= IBS_NR_SAMPLES)
> 
> == seems more appropriate to me.  If it's > then something went wrong
> and we lost data.

Makes sense, will try that.

> 
>> +		next = 0;
>> +
>> +	*s = ibs_pcpu->samples[ibs_pcpu->tail];
>> +	ibs_pcpu->tail = next;
>> +	return 1;
>> +}
> 
> 
>> +static void setup_APIC_ibs(void)
>> +{
>> +	int offset;
>> +
>> +	offset = get_ibs_lvt_offset();
>> +	if (offset < 0)
>> +		goto failed;
>> +
>> +	if (!setup_APIC_eilvt(offset, 0, APIC_EILVT_MSG_NMI, 0))
>> +		return;
>> +failed:
>> +	pr_warn("IBS APIC setup failed on cpu #%d\n",
>> +		smp_processor_id());
> 
> Unless this is going to get more complex, move that up to the if () block
> above and return directly there.

I want to print a warning for both the cases: when LVT offset couldn't
be obtained and also when LVT entry couldn't be setup.

Regards,
Bharata.