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 ;) > Realistically, the only way to have multiple > exceptions without going into the weeds is if KVM somehow restarted the faulting > instruction. That would essentially require very precise memory corruption to > undo the exception fixup handler's modification of RIP on the stack. And at that > point, one could also argue that KVM could also corrupt the exception counter. I wasn't concerned about memory corruption per se but more of a broken emulation as in not generating an exception at all. But ASM_TRY() handles this by resetting the per-cpu exception state. So yeah, looks like I can make use of the per-cpu helpers for my purpose. > >> PS: Would be nice if the entry barrier for new tests wouldn't require to >> handle the accumulated technical debt of the file one's touching ;P > > Heh, and if wishes were horses we'd all be eating steak. Just be glad I didn't > ask you to rewrite the entire test ;-) > > Joking aside, coercing/extorting contributors into using new/better infrastructure > is the only feasible way to keep KVM's test infrastructure somewhat manageable. I understand that, so it's fine with me to enrich my new test case with some cleanups along the way. > E.g. I would love to be able to dedicate a substantial portion of my time to > cleaning up the many warts KUT, but the unfortunate reality is that test infrastructure > is always going to be lower priority than the product itself. I feel your pain and in my case the product is something completely different even, so even less time on my side :/ Thanks, Mathias
