On Wed, Aug 24, 2022, Maxim Levitsky wrote: > On Wed, 2022-08-24 at 14:43 +0000, Sean Christopherson wrote: > > On Wed, Aug 24, 2022, Maxim Levitsky wrote: > > > I noticed that 'fix_hypercall_test' selftest fails if run in a VM. The reason is > > > that L0 patches the hypercall before L1 sees it so it can't really do anything > > > about it. > > > > > > Do you think we can always stop patching hypercalls for the nested guest regardless > > > of the quirk, or that too will be considered breaking backwards compatability? > > > > Heh, go run it on Intel, problem solved ;-) > > > > As discussed last year[*], it's impossible to get this right in all cases, ignoring > > the fact that patching in the first place is arguably wrong. E.g. if KVM is running > > on AMD hardware and L0 exposes an Intel vCPU to L1, then it sadly becomes KVM's > > responsibility to patch L2 because from L1's perspective, a #UD on Intel's VMCALL > > in L2 is spurious. > > > > Regardless of what path we take, I do think we should align VMX and SVM on exception > > intercept behavior. > > Maybe then we should at least skip the unit test if running nested (should be > easy to check the hypervisor cpuid)? My preference is to keep the test as is. It's not completely useless in a VM, e.g. Intel works (currently), non-KVM VMs may or may not work, and VMMs that disable the quirk in L0 will also work. max_guest_memory_test is in a similar boat. Running that in L1 is not recommended as KVM's shadow paging just can't keep up. But that doesn't mean that the test should _never_ be run in L1. If we have the test skip itself, then opting in requires a code change. On the other hand, skipping the test in whatever script is being used to run selftests is easy enough, e.g. `grep hypervisor /proc/cpuinfo`. IMO running test via `make` is a complete mess and should be avoided anyways :-)
