• Sean Christopherson's avatar
    KVM: x86: Rename kvm_x86_ops pointers to align w/ preferred vendor names · e27bc044
    Sean Christopherson authored
    Rename a variety of kvm_x86_op function pointers so that preferred name
    for vendor implementations follows the pattern <vendor>_<function>, e.g.
    rename .run() to .vcpu_run() to match {svm,vmx}_vcpu_run().  This will
    allow vendor implementations to be wired up via the KVM_X86_OP macro.
    
    In many cases, VMX and SVM "disagree" on the preferred name, though in
    reality it's VMX and x86 that disagree as SVM blindly prepended _svm to
    the kvm_x86_ops name.  Justification for using the VMX nomenclature:
    
      - set_{irq,nmi} => inject_{irq,nmi} because the helper is injecting an
        event that has already been "set" in e.g. the vIRR.  SVM's relevant
        VMCB field is even named event_inj, and KVM's stat is irq_injections.
    
      - prepare_guest_switch => prepare_switch_to_guest because the former is
        ambiguous, e.g. it could mean switching between multiple guests,
        switching from the guest to host, etc...
    
      - update_pi_irte => pi_update_irte to allow for matching match the rest
        of VMX's posted interrupt naming scheme, which is vmx_pi_<blah>().
    
      - start_assignment => pi_start_assignment to again follow VMX's posted
        interrupt naming scheme, and to provide context for what bit of code
        might care about an otherwise undescribed "assignment".
    
    The "tlb_flush" => "flush_tlb" creates an inconsistency with respect to
    Hyper-V's "tlb_remote_flush" hooks, but Hyper-V really is the one that's
    wrong.  x86, VMX, and SVM all use flush_tlb, and even common KVM is on a
    variant of the bandwagon with "kvm_flush_remote_tlbs", e.g. a more
    appropriate name for the Hyper-V hooks would be flush_remote_tlbs.  Leave
    that change for another time as the Hyper-V hooks always start as NULL,
    i.e. the name doesn't matter for using kvm-x86-ops.h, and changing all
    names requires an astounding amount of churn.
    
    VMX and SVM function names are intentionally left as is to minimize the
    diff.  Both VMX and SVM will need to rename even more functions in order
    to fully utilize KVM_X86_OPS, i.e. an additional patch for each is
    inevitable.
    
    No functional change intended.
    Signed-off-by: default avatarSean Christopherson <seanjc@google.com>
    Message-Id: <20220128005208.4008533-5-seanjc@google.com>
    Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
    e27bc044
svm.c 131 KB