kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Oliver Upton <oupton@google.com>, kvm@vger.kernel.org
Cc: Jim Mattson <jmattson@google.com>,
	Peter Shier <pshier@google.com>,
	Sean Christopherson <sean.j.christopherson@intel.com>
Subject: Re: [PATCH v3 0/5] Handle monitor trap flag during instruction emulation
Date: Wed, 12 Feb 2020 12:34:36 +0100	[thread overview]
Message-ID: <045fcfb5-8578-ad22-7c3e-6bbf20c4ea35@redhat.com> (raw)
In-Reply-To: <20200207103608.110305-1-oupton@google.com>

On 07/02/20 11:36, Oliver Upton wrote:
> v1: http://lore.kernel.org/r/20200113221053.22053-1-oupton@google.com
> v2: http://lore.kernel.org/r/20200128092715.69429-1-oupton@google.com
> 
> v1 => v2:
>  - Don't split the #DB delivery by vendors. Unconditionally injecting
>    #DB payloads into the 'pending debug exceptions' field will cause KVM
>    to get stuck in a loop. Per the SDM, when hardware injects an event
>    resulting from this field's value, it is checked against the
>    exception interception bitmap.
>  - Address Sean's comments by injecting the VM-exit into L1 from
>    vmx_check_nested_events().
>  - Added fix for nested INIT VM-exits + 'pending debug exceptions' field
>    as it was noticed in implementing v2.
>  - Drop Peter + Jim's Reviewed-by tags, as the patch set has changed
>    since v1.
> 
> v2 => v3:
>  - Merge the check/set_pending_dbg helpers into a single helper,
>    vmx_update_pending_dbg(). Add clarifying comment to this helper.
>  - Rewrite commit message, descriptive comment for change in 3/5 to
>    explicitly describe the reason for mutating payload delivery
>    behavior.
>  - Undo the changes to kvm_vcpu_do_singlestep(). Instead, add a new hook
>    to call for 'full' instruction emulation + 'fast' emulation.
> 
> 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 corrects a nuanced difference between the definition of
> a #DB exception payload field and DR6 register. Mask off bit 12 which is
> defined in the 'pending debug exceptions' field when applying to DR6,
> since the payload field is said to be compatible with the aforementioned
> VMCS field.
> 
> The second patch sets the 'pending debug exceptions' VMCS field when
> delivering an INIT signal VM-exit to L1, as described in the SDM. This
> patch also introduces helpers for setting the 'pending debug exceptions'
> VMCS field.
> 
> The third patch massages KVM's handling of exception payloads with
> regard to API compatibility. Rather than immediately delivering the
> payload w/o opt-in, instead defer the payload + inject
> before completing a KVM_GET_VCPU_EVENTS. This maintains API
> compatibility whilst correcting #DB behavior with regard to higher
> priority VM-exit events.
> 
> Fourth patch introduces MTF implementation for emulated instructions.
> Identify if an MTF is due on an instruction boundary from
> kvm_vcpu_do_singlestep(), however only deliver this VM-exit from
> vmx_check_nested_events() to respect the relative prioritization to
> other VM-exits. Since this augments the nested state, introduce a new
> flag for (de)serialization.
> 
> Last patch adds tests to kvm-unit-tests to assert the correctness of MTF
> under several conditions (concurrent #DB trap, #DB fault, etc). These
> tests pass under virtualization with this series as well as on
> bare-metal.
> 
> Based on commit 2c2787938512 ("KVM: selftests: Stop memslot creation in
> KVM internal memslot region").
> 
> Oliver Upton (4):
>   KVM: x86: Mask off reserved bit from #DB exception payload
>   KVM: nVMX: Handle pending #DB when injecting INIT VM-exit
>   KVM: x86: Deliver exception payload on KVM_GET_VCPU_EVENTS
>   KVM: nVMX: Emulate MTF when performing instruction emulation
> 
>  arch/x86/include/asm/kvm_host.h |  1 +
>  arch/x86/include/uapi/asm/kvm.h |  1 +
>  arch/x86/kvm/svm.c              |  1 +
>  arch/x86/kvm/vmx/nested.c       | 54 ++++++++++++++++++++++++++++++++-
>  arch/x86/kvm/vmx/nested.h       |  5 +++
>  arch/x86/kvm/vmx/vmx.c          | 37 +++++++++++++++++++++-
>  arch/x86/kvm/vmx/vmx.h          |  3 ++
>  arch/x86/kvm/x86.c              | 39 ++++++++++++++++--------
>  8 files changed, 126 insertions(+), 15 deletions(-)
> 

Queued (for 5.6-rc2), thanks.

Paolo


  parent reply	other threads:[~2020-02-12 11:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-07 10:36 [PATCH v3 0/5] Handle monitor trap flag during instruction emulation Oliver Upton
2020-02-07 10:36 ` [PATCH v3 1/5] KVM: x86: Mask off reserved bit from #DB exception payload Oliver Upton
2020-02-07 10:36 ` [PATCH v3 2/5] KVM: nVMX: Handle pending #DB when injecting INIT VM-exit Oliver Upton
2020-02-07 10:36 ` [PATCH v3 3/5] KVM: x86: Deliver exception payload on KVM_GET_VCPU_EVENTS Oliver Upton
2020-02-07 10:36 ` [PATCH v3 4/5] KVM: nVMX: Emulate MTF when performing instruction emulation Oliver Upton
2020-02-07 10:36 ` [kvm-unit-tests PATCH v3 5/5] x86: VMX: Add tests for monitor trap flag Oliver Upton
2020-02-25  0:09   ` Oliver Upton
2020-02-25  7:36     ` Paolo Bonzini
2020-02-25  7:52       ` Oliver Upton
2020-02-26  0:13     ` Krish Sadhukhan
2020-02-26  0:55       ` Oliver Upton
2020-02-12 11:34 ` Paolo Bonzini [this message]
2020-02-27  0:22   ` [PATCH v3 0/5] Handle monitor trap flag during instruction emulation Oliver Upton
2020-02-27  6:37     ` Paolo Bonzini
2020-02-27  9:11       ` Oliver Upton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=045fcfb5-8578-ad22-7c3e-6bbf20c4ea35@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=oupton@google.com \
    --cc=pshier@google.com \
    --cc=sean.j.christopherson@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).