> >> +The "reason" field specifies why the MSR trap occurred. User space will only > >> +receive MSR exit traps when a particular reason was requested during through > >> +ENABLE_CAP. Currently valid exit reasons are: > >> + > >> + KVM_MSR_EXIT_REASON_INVAL - access to invalid MSRs or reserved bits > > > > > > Can we also have ENOENT? > > KVM_MSR_EXIT_REASON_ENOENT - Unknown MSR > > I tried to add that at first, but it gets tricky really fast. Why should > user space have a vested interest in differentiating between "MSR is not > implemented" and "MSR is guarded by a CPUID flag and thus not handled" > or "MSR is guarded by a CAP"? > > The more details we reveal, the more likely we're to break ABI > compatibility. > I don't suspect we will ever have a stable ABI here, whether we split the two error values or not. But there could be value in it. Consider an MSR that raises #GP if any bit in the high dword is set. KVM version 0 knows nothing about this MSR, but KVM version 1 implements it properly. Assuming ignore_msrs=0 and error codes: EINVAL (invalid argument, should raise a #GP) and ENOTSUP (seems like a better name than ENOENT, Unknown MSR). With Just EINVAL: KVM version 0 will always exit to userspace if EINVAL is requested (it needs help). KVM version 1 will exit to userspace only for illegal accesses if EINVAL is requested (but it doesn't really need help). With EINVAL and ENOTSUP: KVM version 0 will always exit to userspace if ENOTSUP is requested (it needs help). KVM version 1 will not exit to userspace if ENOTSUP is requested. If you want to implement ignore_msrs in userspace it seems much easier with the second approach, and I think all you'd have to do is return -ENOTSUP from kvm_msr_ignored_check() instead of returning 1.
