[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bb6a554f-4823-59ce-16a4-48bd5b911d63@amd.com>
Date: Mon, 6 May 2024 11:05:17 -0500
From: Tom Lendacky <thomas.lendacky@....com>
To: Ravi Bangoria <ravi.bangoria@....com>, tglx@...utronix.de,
mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
seanjc@...gle.com, pbonzini@...hat.com
Cc: hpa@...or.com, rmk+kernel@...linux.org.uk, peterz@...radead.org,
james.morse@....com, lukas.bulwahn@...il.com, arjan@...ux.intel.com,
j.granados@...sung.com, sibs@...natelecom.cn, nik.borisov@...e.com,
michael.roth@....com, nikunj.dadhania@....com, babu.moger@....com,
x86@...nel.org, kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
santosh.shukla@....com, ananth.narayan@....com, sandipan.das@....com
Subject: Re: [PATCH 2/3] x86/bus_lock: Add support for AMD
On 4/29/24 01:06, Ravi Bangoria wrote:
> Upcoming AMD uarch will support Bus Lock Detect (called Bus Lock Trap
> in AMD docs). Add support for the same in Linux. Bus Lock Detect is
> enumerated with cpuid CPUID Fn0000_0007_ECX_x0 bit [24 / BUSLOCKTRAP].
> It can be enabled through MSR_IA32_DEBUGCTLMSR. When enabled, hardware
> clears DR6[11] and raises a #DB exception on occurrence of Bus Lock if
> CPL > 0. More detail about the feature can be found in AMD APM[1].
>
> [1]: AMD64 Architecture Programmer's Manual Pub. 40332, Rev. 4.07 - June
> 2023, Vol 2, 13.1.3.6 Bus Lock Trap
> https://bugzilla.kernel.org/attachment.cgi?id=304653
>
> Signed-off-by: Ravi Bangoria <ravi.bangoria@....com>
> ---
> arch/x86/kernel/cpu/amd.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 39f316d50ae4..013d16479a24 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -1058,6 +1058,8 @@ static void init_amd(struct cpuinfo_x86 *c)
>
> /* AMD CPUs don't need fencing after x2APIC/TSC_DEADLINE MSR writes. */
> clear_cpu_cap(c, X86_FEATURE_APIC_MSRS_FENCE);
> +
> + bus_lock_init();
Can this call and the one in the intel.c be moved to common.c?
Thanks,
Tom
> }
>
> #ifdef CONFIG_X86_32
Powered by blists - more mailing lists