Re: [PATCH v20 14/14] KVM: selftests: arm64: Add GCS EXLOCK exception emulation test

[Leonardo Bras <leo.bras@arm.com>]

On Thu, Sep 10, 2026 at 07:26:59PM +0100, Mark Brown wrote:
> 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.

Okay then,

> 
> > If I got the workings right, and both above suggestions (0x1A and 
> > bool->int) are either fixed or considered not an issue, then:
> 
> Thanks.

Thank you!
Leo