Re: [PATCH 06/27] arm64: Add debug registers affected by HDFGxTR_EL2

From: Marc Zyngier <maz@kernel.org>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Eric Auger <eric.auger@redhat.com>,
	Mark Brown <broonie@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Will Deacon <will@kernel.org>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Andre Przywara <andre.przywara@arm.com>,
	Chase Conklin <chase.conklin@arm.com>,
	Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>,
	Darren Hart <darren@os.amperecomputing.com>,
	Miguel Luis <miguel.luis@oracle.com>,
	James Morse <james.morse@arm.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Anshuman Khandual <anshuman.khandual@arm.com>
Subject: Re: [PATCH 06/27] arm64: Add debug registers affected by HDFGxTR_EL2
Date: Thu, 27 Jul 2023 16:42:08 +0100	[thread overview]
Message-ID: <6e855aa9b49000edd555c75d206cc777@kernel.org> (raw)
In-Reply-To: <0c26ba18-1d82-b9c0-3643-bd8e4d2f58f4@arm.com>

On 2023-07-19 12:00, Suzuki K Poulose wrote:
> Hi Marc
> 
> On 12/07/2023 15:57, Marc Zyngier wrote:
>> The HDFGxTR_EL2 registers trap a (huge) set of debug and trace
>> related registers. Add their encodings (and only that, because
>> we really don't care about what these registers actually do at
>> this stage).
>> 
>> Signed-off-by: Marc Zyngier <maz@kernel.org>
>> ---
>>   arch/arm64/include/asm/sysreg.h | 78 
>> +++++++++++++++++++++++++++++++++
>>   1 file changed, 78 insertions(+)
>> 
>> diff --git a/arch/arm64/include/asm/sysreg.h 
>> b/arch/arm64/include/asm/sysreg.h
>> index 76289339b43b..9dfd127be55a 100644
>> --- a/arch/arm64/include/asm/sysreg.h
>> +++ b/arch/arm64/include/asm/sysreg.h
>> @@ -194,6 +194,84 @@
>>   #define SYS_DBGDTRTX_EL0		sys_reg(2, 3, 0, 5, 0)
>>   #define SYS_DBGVCR32_EL2		sys_reg(2, 4, 0, 7, 0)
>>   +#define SYS_BRBINF_EL1(n)		sys_reg(2, 1, 8, (n & 15), (((n & 16) >> 
>> 2) | 0))
>> +#define SYS_BRBINFINJ_EL1		sys_reg(2, 1, 9, 1, 0)
>> +#define SYS_BRBSRC_EL1(n)		sys_reg(2, 1, 8, (n & 15), (((n & 16) >> 
>> 2) | 1))
>> +#define SYS_BRBSRCINJ_EL1		sys_reg(2, 1, 9, 1, 1)
>> +#define SYS_BRBTGT_EL1(n)		sys_reg(2, 1, 8, (n & 15), (((n & 16) >> 
>> 2) | 2))
>> +#define SYS_BRBTGTINJ_EL1		sys_reg(2, 1, 9, 1, 2)
>> +#define SYS_BRBTS_EL1			sys_reg(2, 1, 9, 0, 2)
>> +
>> +#define SYS_BRBCR_EL1			sys_reg(2, 1, 9, 0, 0)
>> +#define SYS_BRBFCR_EL1			sys_reg(2, 1, 9, 0, 1)
>> +#define SYS_BRBIDR0_EL1			sys_reg(2, 1, 9, 2, 0)
>> +
> 
> Merge conflict alert. The above are being added as part of the BRBE
> support series from Anshuman [0], though in a slightly different
> scheme
> for registers with numbers. e.g, SYS_BRBINF_EL1(0) vs SYS_BRBINF0_EL1.
> That series is not merged yet, but might go in this cycle.

Thanks for the heads up!

I'm pretty confident that this will not conflict too badly, as the
#defines are different. But I can always drag a prefix of Anshuman's
series into the KVM tree and resolve it there.

Cheers,

         M.
-- 
Jazz is not dead. It just smells funny...