On Sat, Sep 5, 2026 at 7:24 PM Tina Zhang <[email protected]> wrote: > > > > On 9/5/2026 7:07 AM, Jim Mattson wrote: > > On Mon, Aug 24, 2026 at 5:40 AM Tina Zhang <[email protected]> wrote: > >> > >> + > >> + vmcb->control.exit_info_1 = exit_info_1; > >> + vmcb->control.exit_info_2 = 0; > >> +} > > > > Can this entire function be integrated into the existing switch > > statement in svm_check_intercept()? > > Yes, that makes sense. > > > > > And, if !guest_cpu_cap_has(vcpu, X86_FEATURE_DECODEASSISTS), should > > exit_info_1 be cleared for these intercepts? > > My reading is that exit_info_1 is undefined for these intercepts when > DecodeAssists is not exposed, and KVM previously left it untouched. I > would therefore prefer to preserve the existing behavior and update > exit_info_1 only when DecodeAssists is exposed. That said, do you see > any reason why KVM should explicitly clear exit_info_1 when > guest_cpu_cap_has(vcpu, X86_FEATURE_DECODEASSISTS) returns false?
You're right. The APM says, "Note that the contents of the EXITINFO1 and EXITINFO2 fields are undefined for intercepts where their use is not indicated," so pre-Bulldozer CPUs would probably have left them alone.
