On Thu, May 14, 2026 at 9:35 AM Sean Christopherson <[email protected]> wrote: > > On Thu, May 14, 2026, Jim Mattson wrote: > > On Thu, May 14, 2026 at 9:20 AM Sean Christopherson <[email protected]> > > wrote: > > > Oooh, this is based on the generic CPL rules. I didn't think about it > > > from that > > > perspective. So yeah, addressing that does make sense. What a pain. > > > > When I fix this in version 4, what's the correct footer for Sashiko > > attribution: > > > > Assisted-by: Sashiko:gemini/gemini-3.1-pro-preview > > > > or > > > > Reported-by: Sashiko:gemini/gemini-3.1-pro-preview > > This, or even just: > > Reported-by: Sashiko > > is good enough for me. I don't expect random developers to know or care what > model was used, at least not when it comes to reporting bugs. If you use AI > to > help write the code, then maybe I'd care?
I had Jetski write an empirical test to see how the hardware behaves. On the first userspace CPUID VM-exit, temporarily set #GP on userspace CPUID per the appropriate vendor's mechanism, make sure that we intercept #GP, and re-enter the guest without advancing RIP. Then, see what the next VM-exit is. Surprise! kvm_intel: KVM: EMPIRICAL TEST RESULT: #GP took precedence over CPUID VM-exit kvm_amd: KVM: EMPIRICAL TEST RESULT (SVM): CPUID VM-exit took precedence over #GP! LOL! David: Is this intentional or a bug?
