Hi Sean,
On Fri, Aug 27, 2021 at 1:12 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> On Fri, Aug 27, 2021, Jing Zhang wrote:
> > Three different exit code ranges are named as low, high and vmgexit,
> > which start from 0x0, 0x400 and 0x80000000.
> >
> > Original-by: Jim Mattson <jmattson@xxxxxxxxxx>
> > Signed-off-by: Jing Zhang <jingzhangos@xxxxxxxxxx>
> > ---
> > arch/x86/include/asm/kvm_host.h | 7 +++++++
> > arch/x86/include/uapi/asm/svm.h | 7 +++++++
> > arch/x86/kvm/svm/svm.c | 21 +++++++++++++++++++++
> > arch/x86/kvm/x86.c | 9 +++++++++
> > 4 files changed, 44 insertions(+)
> >
> > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> > index dd2380c9ea96..6e3c11a29afe 100644
> > --- a/arch/x86/include/asm/kvm_host.h
> > +++ b/arch/x86/include/asm/kvm_host.h
> > @@ -35,6 +35,7 @@
> > #include <asm/kvm_vcpu_regs.h>
> > #include <asm/hyperv-tlfs.h>
> > #include <asm/vmx.h>
> > +#include <asm/svm.h>
> >
> > #define __KVM_HAVE_ARCH_VCPU_DEBUGFS
> >
> > @@ -1261,6 +1262,12 @@ struct kvm_vcpu_stat {
> > u64 vmx_all_exits[EXIT_REASON_NUM];
> > u64 vmx_l2_exits[EXIT_REASON_NUM];
> > u64 vmx_nested_exits[EXIT_REASON_NUM];
> > + u64 svm_exits_low[SVM_EXIT_LOW_END - SVM_EXIT_LOW_START];
> > + u64 svm_exits_high[SVM_EXIT_HIGH_END - SVM_EXIT_HIGH_START];
> > + u64 svm_vmgexits[SVM_VMGEXIT_END - SVM_VMGEXIT_START];
>
> This is, for lack of a better word, a very lazy approach. With a bit more (ok,
> probably a lot more) effort and abstraction, we can have parity between VMX and
> SVM, and eliminate a bunch of dead weight. Having rough parity would likely be
> quite helpful for the end user, e.g. reduces/eliminates vendor specific userspace
> code.
>
> E.g. this more or less doubles the memory footprint due to tracking VMX and SVM
> separately, SVM has finer granularity than VMX (often too fine), VMX tracks nested
> exits but SVM does not, etc...
>
> If we use KVM-defined exit reasons, then we can omit the exits that should never
> happen (SVM has quite a few), and consolidate the ones no one should ever care
> about, e.g. DR0..DR4 and DR6 can be collapsed (if I'm remembering my DR aliases
> correctly). And on the VMX side we can provide better granularity than the raw
> exit reason, e.g. VMX's bundling of NMIs and exceptions is downright gross.
>
> #define KVM_GUEST_EXIT_READ_CR0
> #define KVM_GUEST_EXIT_READ_CR3
> #define KVM_GUEST_EXIT_READ_CR4
> #define KVM_GUEST_EXIT_READ_CR8
> #define KVM_GUEST_EXIT_DR_READ
> #define KVM_GUEST_EXIT_DR_WRITE
> #define KVM_GUEST_EXIT_DB_EXCEPTION
> #define KVM_GUEST_EXIT_BP_EXCEPTION
> #define KVM_GUEST_EXIT_UD_EXCEPTION
>
> ...
> #define KVM_NR_GUEST_EXIT_REASONS
>
> u64 l1_exits[KVM_NR_GUEST_EXIT_REASONS];
> u64 l2_exits[KVM_NR_GUEST_EXIT_REASONS];
> u64 nested_exits[KVM_NR_GUEST_EXIT_REASONS];
>
>
> The downside is that it will require KVM-defined exit reasons and will have a
> slightly higher maintenance cost because of it, but I think overall it would be
> a net positive. Paolo can probably even concoct some clever arithmetic to avoid
> conditionals when massaging SVM exits reasons. VMX will require a bit more
> manual effort, especially to play nice with nested, but in the end I think we'll
> be happier.
>
Thanks for the suggestions. Will try to generalize the exit reasons
and see how it is going.
Jing
> > + u64 svm_vmgexit_unsupported_event;
> > + u64 svm_exit_sw;
> > + u64 svm_exit_err;
> > };
