On Thu, Apr 13, 2023, Mathias Krause wrote: > On 06.04.23 18:43, Sean Christopherson wrote: > > On Thu, Apr 06, 2023, Mathias Krause wrote: > >> On 06.04.23 05:02, Sean Christopherson wrote: > >>> [...] > >>> E.g. I believe this can be something like: > >>> > >>> asm_safe_report_ex(GP_VECTOR, "orq $0, (%[noncanonical]), "r" (NONCANONICAL)); > >>> report(!exception_error_code()); > >>> > >>> Or we could even add asm_safe_report_ex_ec(), e.g. > >>> > >>> asm_safe_report_ex_ec(GP_VECTOR, 0, > >>> "orq $0, (%[noncanonical]), "r" (NONCANONICAL)); > >> > >> Yeah, the latter. Verifying the error code is part of the test, so that > >> should be preserved. > >> > >> The tests as written by me also ensure that an exception actually > >> occurred, exactly one, actually. Maybe that should be accounted for in > >> asm_safe*() as well? > > > > That's accounted for, the ASM_TRY() machinery treats "0" as no exception (we > > sacrified #DE for the greater good). > > I overlooked the GS-relative MOVL in ASM_TRY() first, which, after some > digging, turns out to be zeroing the per-cpu 'exception_data' member. > Sneaky ;) Heh, "sneaky" is a much more polite description than I would use. I really don't like using per-CPU data for excpetion fixup, but having to support 32-bit builds means our options our limited. E.g. KVM selftests is 64-bit only and so can use r9-r11 to communicate with the exception handler without conflicting with instructions that have hardcoded registers (testing SYSRET isn't exactly a priority).
