kernel/tools/testing/selftests/kvm/x86/fastops_test.c, branch linux-rolling-stable

KVM: selftests: Add support for DIV and IDIV in the fastops test

2025-09-11T15:55:44Z

Extend the fastops test coverage to DIV and IDIV, specifically to provide coverage for #DE (divide error) exceptions, as #DE is the only exception that can occur in KVM's fastops path, i.e. that requires exception fixup. Link: https://lore.kernel.org/r/20250909202835.333554-5-seanjc@google.com Signed-off-by: Sean Christopherson

KVM: selftests: Dedup the gnarly constraints of the fastops tests (more macros!)

2025-09-11T15:55:44Z

Add a fastop() macro along with macros to define its required constraints, and use the macros to dedup the innermost guts of the fastop testcases. No functional change intended. Link: https://lore.kernel.org/r/20250909202835.333554-4-seanjc@google.com Signed-off-by: Sean Christopherson

KVM: selftests: Add coverage for 'b' (byte) sized fastops emulation

2025-09-11T15:55:44Z

Extend the fastops test to cover instructions that operate on 8-bit data. Support for 8-bit instructions was omitted from the original commit purely due to complications with BT not having a r/m8 variant. To keep the RFLAGS.CF behavior deterministic and not heavily biased to '0' or '1', continue using BT, but cast and load the to-be-tested value into a dedicated 32-bit constraint. Supporting 8-bit operations will allow using guest_test_fastops() as-is to provide full coverage for DIV and IDIV. For divide operations, covering all operand sizes _is_ interesting, because KVM needs provide exception fixup for each size (failure to handle a #DE could panic the host). Link: https://lore.kernel.org/all/aIF7ZhWZxlkcpm4y@google.com Link: https://lore.kernel.org/r/20250909202835.333554-3-seanjc@google.com Signed-off-by: Sean Christopherson

KVM: selftests: Add a test for x86's fastops emulation

2025-05-08T14:16:44Z

Add a test to verify KVM's fastops emulation via forced emulation. KVM's so called "fastop" infrastructure executes the to-be-emulated instruction directly on hardware instead of manually emulating the instruction in software, using various shenanigans to glue together the emulator context and CPU state, e.g. to get RFLAGS fed into the instruction and back out for the emulator. Add testcases for all instructions that are low hanging fruit. While the primary goal of the selftest is to validate the glue code, a secondary goal is to ensure "emulation" matches hardware exactly, including for arithmetic flags that are architecturally undefined. While arithmetic flags may be *architecturally* undefined, their behavior is deterministic for a given CPU (likely a given uarch, and possibly even an entire family or class of CPUs). I.e. KVM has effectively been emulating underlying hardware behavior for years. Link: https://lore.kernel.org/r/20250506011250.1089254-1-seanjc@google.com Signed-off-by: Sean Christopherson