[PATCH v20 14/14] KVM: selftests: arm64: Add GCS EXLOCK exception emulation test
Mark Brown
broonie at kernel.org
Thu Sep 10 11:26:59 PDT 2026
On Thu, Sep 10, 2026 at 06:20:30PM +0100, Leonardo Bras wrote:
> The part of re-running test_udf_exception() with HFGITR_EL2 set, IIUC, it
> that part of fine-grained traps. It seems correct, although I am not seeing
> any tests of the EC syndrome being 0x1A to make sure it's in use.
Now that I look again this isn't actually effective anyway, we would
need to run the guest code at emulated EL1 which for something that's
basically just a double check. I'll just delete the extra runs.
> There are also a lot of expect_exlock being used as an int, even if it's a
> bool. I understand the idea of summing it as we expect it to be 1 on true
> or 0 on false, but is it really ok?
> Maybe we could change it to int, so we just set it when we enter
> test_sysreg() or test_udf_exception() like:
> - expect_exlock = enable_exlock;
> + expect_exlock = enable_exlock ? 1 : 0;
The conversions between int and and boolean values are part of the C
spec and widely used within the kernel, we don't need to open code it.
A zero in a boolean context is false, any other integer is true.
Similarly false in an integer context is 0, and true is 1.
> If I got the workings right, and both above suggestions (0x1A and
> bool->int) are either fixed or considered not an issue, then:
Thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260910/2648dc6e/attachment.sig>
More information about the linux-arm-kernel
mailing list