Jim Mattson <jmattson@xxxxxxxxxx> writes: ... > On>> >> > I know I was the one to complain about the #GP, but... >> >> > >> >> > As a general rule, kvm cannot always guarantee a #UD for an >> >> > instruction that is hidden from the guest. Consider, for example, >> >> > popcnt, aesenc, vzeroall, movbe, addcx, clwb, ... >> >> > I'm pretty sure that Paolo has brought this up in the past when I've >> >> > made similar complaints. >> >> >> >> Ofcourse, even for vm instructions failures, the fixup table always jumps >> >> to a ud2. I was just trying to address the concern because it is possible >> >> to inject the correct exception via decoding the instruction. >> > >> > But kvm doesn't intercept #GP, except when enable_vmware_backdoor is >> > set, does it? I don't think it's worth intercepting #GP just to get >> > this #UD right. >> >> I prefer following the spec wherever we can. > > One has to wonder why userspace is even trying to execute a privileged > instruction not enumerated by CPUID, unless it's just trying to expose > virtualization inconsistencies. Perhaps this could be controlled by a > new module parameter: "pedantic." > Yeah, fair point. >> Otoh, if kvm can't guarantee injecting the right exception, >> we should change kvm-unit-tests to just check for exceptions and not a specific >> exception that adheres to the spec. This one's fine though, as long as we don't add >> a CPL > 0 invpcid test, the other patch that was posted fixes it. > > KVM *can* guarantee the correct exception, but it requires > intercepting all #GPs. That's probably not a big deal, but it is a > non-zero cost. Is it the right tradeoff to make? Not all, we intercept GPs only under a specific condition - just as we do for vmware_backdoor and for the recent amd errata. IMO, I think it's the right tradeoff to make to get guest exceptions right. Bandan
