Re: [PATCH 0/3] Handle monitor trap flag during instruction emulation

[Sean Christopherson <sean.j.christopherson@intel.com>]

On Mon, Jan 13, 2020 at 02:10:50PM -0800, Oliver Upton wrote:
> KVM already provides guests the ability to use the 'monitor trap flag'
> VM-execution control. Support for this flag is provided by the fact that
> KVM unconditionally forwards MTF VM-exits to the guest (if requested),
> as KVM doesn't utilize MTF. While this provides support during hardware
> instruction execution, it is insufficient for instruction emulation.
> 
> Should L0 emulate an instruction on the behalf of L2, L0 should also
> synthesize an MTF VM-exit into L1, should control be set.
> 
> The first patch fixes the handling of #DB payloads for both Intel and
> AMD. To support MTF, KVM must also populate the 'pending debug
> exceptions' field, rather than directly manipulating the debug register
> state. Additionally, the exception payload associated with #DB is said
> to be compatible with the 'pending debug exceptions' field in VMX. This
> does not map cleanly into an AMD DR6 register, requiring bit 12 (enabled
> breakpoint on Intel, reserved MBZ on AMD) to be masked off.
> 
> The second patch implements MTF under instruction emulation by adding
> vendor-specific hooks to kvm_skip_emulated_instruction(). Should any
> non-debug exception be pending before this call, MTF will follow event
> delivery. Otherwise, an MTF VM-exit may be synthesized directly into L1.
> 
> Third patch introduces tests to kvm-unit-tests. These tests path both
> under virtualization and on bare-metal.
> 
> Oliver Upton (2):
>   KVM: x86: Add vendor-specific #DB payload delivery
>   KVM: x86: Emulate MTF when performing instruction emulation
> 
>  arch/x86/include/asm/kvm_host.h |  2 ++
>  arch/x86/kvm/svm.c              | 25 +++++++++++++++++++++
>  arch/x86/kvm/vmx/nested.c       |  2 +-
>  arch/x86/kvm/vmx/nested.h       |  5 +++++
>  arch/x86/kvm/vmx/vmx.c          | 39 ++++++++++++++++++++++++++++++++-
>  arch/x86/kvm/x86.c              | 27 ++++++-----------------
>  6 files changed, 78 insertions(+), 22 deletions(-)
> 
> -- 

What commit is this series based on?  It doesn't apply cleanly on the
current kvm/master or kvm/queue.