Re: [PATCH 0/3] AMD invpcid exception fix

[Bandan Das <bsd@redhat.com>]

Jim Mattson <jmattson@google.com> 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