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
