On Mon, May 24, 2021, Paolo Bonzini wrote: > On 24/05/21 15:58, Tom Lendacky wrote: > > > Would it hurt if we just move 'vcpu->arch.guest_state_protected' check > > > to is_64_bit_mode() itself? It seems to be too easy to miss this > > > peculiar detail about SEV in review if new is_64_bit_mode() users are to > > > be added. > > I thought about that, but wondered if is_64_bit_mode() was to be used in > > other places in the future, if it would be a concern. I think it would be > > safe since anyone adding it to a new section of code is likely to look at > > what that function is doing first. > > > > I'm ok with this. Paolo, I know you already queued this, but would you > > prefer moving the check into is_64_bit_mode()? > > Let's introduce a new wrapper is_64_bit_hypercall, and add a > WARN_ON_ONCE(vcpu->arch.guest_state_protected) to is_64_bit_mode. Can we introduce the WARN(s) in a separate patch, and deploy them much more widely than just is_64_bit_mode()? I would like to have them lying in wait at every path that should be unreachable, e.g. get/set segments, get_cpl(), etc... Side topic, kvm_get_cs_db_l_bits() should be moved to svm.c. Functionally, it's fine to have it as a vendor-agnostic helper, but practically speaking it should never be called directly.
