Re: [PATCH v3 02/12] KVM: arm64: selftests: Add write_sysreg_s and read_sysreg_s
flat view
From: Andrew Jones <hidden>
Date: 2021-09-02 12:31:19
Also in:
kvmarm, linux-arm-kernel, lkml
On Wed, Sep 01, 2021 at 11:06:10PM +0000, Oliver Upton wrote:
On Wed, Sep 01, 2021 at 03:48:40PM -0700, Raghavendra Rao Ananta wrote:quoted
On Wed, Sep 1, 2021 at 3:08 PM Oliver Upton [off-list ref] wrote:quoted
On Wed, Sep 01, 2021 at 09:28:28PM +0000, Oliver Upton wrote:quoted
On Wed, Sep 01, 2021 at 09:14:02PM +0000, Raghavendra Rao Ananta wrote:quoted
For register names that are unsupported by the assembler or the ones without architectural names, add the macros write_sysreg_s and read_sysreg_s to support them. The functionality is derived from kvm-unit-tests and kernel's arch/arm64/include/asm/sysreg.h. Signed-off-by: Raghavendra Rao Ananta <redacted>Would it be possible to just include <asm/sysreg.h>? See tools/arch/arm64/include/asm/sysreg.hGeez, sorry for the noise. I mistakenly searched from the root of my repository, not the tools/ directory.No worries :)quoted
In any case, you could perhaps just drop the kernel header there just to use the exact same source for kernel and selftest.You mean just copy/paste the entire header? There's a lot of stuff in there which we don't need it (yet).Right. It's mostly register definitions, which I don't think is too high of an overhead. Don't know where others stand, but I would prefer a header that is equivalent between kernel & selftests over a concise header.
Until now we haven't needed the sys_reg(...) type of definitions for sysregs in selftests. In case we did, we defined the registers we needed for get/set_one_reg by their parts, e.g. #define ID_AA64DFR0_EL1 3, 0, 0, 5, 0 allowing us to choose how we use them, ARM64_SYS_REG(...) vs. sys_reg(...). Bringing over sysreg.h is probably a good idea though. If we do, then I'd suggest we define a new macro that allows us to convert a SYS_* register definition from sysreg.h into an ARM64_SYS_REG definition for get/set_one_reg in order to avoid redundant definitions. Thanks, drew