On Sat, Aug 03, 2024 at 10:35:54AM +0100, Marc Zyngier wrote: > Mark Brown <broonie@xxxxxxxxxx> wrote: > > This conversion was done with the sed command: > > sed -i -E 's-ARM64_SYS_REG.*/\* (.*) \*/-KVM_ARM64_SYS_REG(SYS_\1),-' tools/testing/selftests/kvm/aarch64/get-reg-list.c > [Eyes rolling] > What I asked about scripting the whole thing, it never occurred to me > that you would use the *comments* as a reliable source of information. > Do we have anything less reliable than comments in the kernel? I think we should ultimately be using both the comments and the encodings - the comments indicate what people thought was being tested and it's useful to make sure we have that coverage even if the implementation were to have been wrong. Doing this step is also going to have picked up registers which we don't yet have in the sysreg file, some of which are going to be painful to add there (things like ESR for example) so aren't likely to get done in a hurry due to complexity in their definitions. This was quick to do, represents progress, and offers a hint to anyone adding new registers that they should use the symbolic definitions. > The matching must be done from the arch/arm64/tools/sysreg file, > because that's the (admittedly dubious) source of truth. We actually > trust the encodings because they are reported by the kernel itself. > The comment is hand-written, and likely wrong. Sure, there's a reason I compared the resulting binaries rather than just trusting that the conversion gave the same result. > > - ARM64_SYS_REG(3, 3, 14, 3, 1), /* CNTV_CTL_EL0 */ > > - ARM64_SYS_REG(3, 3, 14, 3, 2), /* CNTV_CVAL_EL0 */ > > + KVM_ARM64_SYS_REG(SYS_CNTV_CTL_EL0), > > + KVM_ARM64_SYS_REG(SYS_CNTV_CVAL_EL0), > > ARM64_SYS_REG(3, 3, 14, 0, 2), > Great. So not only you fail convert a register, but you also ignore > the nugget described in arch/arm64/invlude/uapi/asm/kvm.h:267. That's that CNTV_CTL_EL0 and CNTV_CVAL_EL0 have their encodings reversed in the ABI. > Sure, having both described hides the crap, as we don't attach any > significance to the registers themselves. But that shows how > untrustworthy the comments are. I'm afraid that any automated conversion is likely to trip over an ABI issue like that - the obvious thing to do when looking up by encoding would be to just emit a KVM_ARM64_SYS_REG() if we find the encoding which would give the same end result. I'll add a separate manual update of these registers. Are there any other similar issues? I didn't spot anything in kvm.h. > > ARM64_SYS_REG(2, 0, 0, 0, 4), > > ARM64_SYS_REG(2, 0, 0, 0, 5), > > ARM64_SYS_REG(2, 0, 0, 0, 6), > As far as I can tell, these registers are not unallocated, and they > should be named. I agree that we should do all named registers eventually, the above are numbered debug registers (DBGBVR0_EL1, DBGBCR0_EL1 and DBGWVR0_EL1) which aren't in the sysreg file yet so wouldn't currently be covered by a conversion based on pulling encodings from there. They could also be done immediately with a generator script as there are DBGBVRn_EL1 style macros there. Like I say this is a quick first step and does improve things, there's still more to do but I do think this moves us forward. We can and should come back later and build on things as people have time.
Attachment:
signature.asc
Description: PGP signature
