From: Paolo Bonzini <pbonzini@redhat.com>
To: Maxim Levitsky <mlevitsk@redhat.com>, kvm@vger.kernel.org
Cc: "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<x86@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Sean Christopherson <seanjc@google.com>,
Marc Zyngier <maz@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
open list <linux-kernel@vger.kernel.org>,
Julien Thierry <julien.thierry.kdev@gmail.com>,
Stefano Garzarella <sgarzare@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Jonathan Corbet <corbet@lwn.net>, Jessica Yu <jeyu@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Jan Kiszka <jan.kiszka@siemens.com>,
Will Deacon <will@kernel.org>,
"open list:KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)"
<kvmarm@lists.cs.columbia.edu>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Vasily Gorbik <gor@linux.ibm.com>, Joerg Roedel <joro@8bytes.org>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
Jim Mattson <jmattson@google.com>,
Cornelia Huck <cohuck@redhat.com>,
David Hildenbrand <david@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Janosch Frank <frankja@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
"open list:S390" <linux-s390@vger.kernel.org>,
Heiko Carstens <hca@linux.ibm.com>,
Kieran Bingham <kbingham@kernel.org>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
"moderated list:KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)"
<linux-arm-kernel@lists.infradead.org>,
James Morse <james.morse@arm.com>
Subject: Re: [PATCH v2 6/9] KVM: x86: implement KVM_GUESTDBG_BLOCKEVENTS
Date: Fri, 2 Apr 2021 19:07:32 +0200 [thread overview]
Message-ID: <f9e1ca0c-d6cb-7477-55f2-c4861d8f8704@redhat.com> (raw)
In-Reply-To: <20210401135451.1004564-7-mlevitsk@redhat.com>
On 01/04/21 15:54, Maxim Levitsky wrote:
> KVM_GUESTDBG_BLOCKEVENTS is a guest debug feature that
> will allow KVM to block all interrupts while running.
> It is mostly intended to be used together with single stepping,
> to make it more robust, and has the following benefits:
>
> * Resuming from a breakpoint is much more reliable:
> When resuming execution from a breakpoint, with interrupts enabled,
> more often than not, KVM would inject an interrupt and make the CPU
> jump immediately to the interrupt handler and eventually return to
> the breakpoint, only to trigger it again.
>
> From the gdb's user point of view it looks like the CPU has never
> executed a single instruction and in some cases that can even
> prevent forward progress, for example, when the breakpoint
> is placed by an automated script (e.g lx-symbols), which does
> something in response to the breakpoint and then continues
> the guest automatically.
> If the script execution takes enough time for another interrupt to
> arrive, the guest will be stuck on the same breakpoint forever.
>
> * Normal single stepping is much more predictable, since it won't
> land the debugger into an interrupt handler.
>
> * Chances of RFLAGS.TF being leaked to the guest are reduced:
>
> KVM sets that flag behind the guest's back to single step it,
> but if the single step lands the vCPU into an
> interrupt/exception handler the RFLAGS.TF will be leaked to the
> guest in the form of being pushed to the stack.
> This doesn't completely eliminate this problem as exceptions
> can still happen, but at least this eliminates the common
> case.
>
> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
The patch uses BLOCKIRQ instead of BLOCKEVENTS.
Paolo
> ---
> Documentation/virt/kvm/api.rst | 1 +
> arch/x86/include/asm/kvm_host.h | 3 ++-
> arch/x86/include/uapi/asm/kvm.h | 1 +
> arch/x86/kvm/x86.c | 4 ++++
> 4 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 9778b2434c03..a4f2dc84741f 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -3338,6 +3338,7 @@ flags which can include the following:
> - KVM_GUESTDBG_INJECT_DB: inject DB type exception [x86]
> - KVM_GUESTDBG_INJECT_BP: inject BP type exception [x86]
> - KVM_GUESTDBG_EXIT_PENDING: trigger an immediate guest exit [s390]
> + - KVM_GUESTDBG_BLOCKIRQ: avoid injecting interrupts/NMI/SMI [x86]
>
> For example KVM_GUESTDBG_USE_SW_BP indicates that software breakpoints
> are enabled in memory so we need to ensure breakpoint exceptions are
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index cc7c82a449d5..8c529ae9dbbe 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -227,7 +227,8 @@ enum x86_intercept_stage;
> KVM_GUESTDBG_USE_HW_BP | \
> KVM_GUESTDBG_USE_SW_BP | \
> KVM_GUESTDBG_INJECT_BP | \
> - KVM_GUESTDBG_INJECT_DB)
> + KVM_GUESTDBG_INJECT_DB | \
> + KVM_GUESTDBG_BLOCKIRQ)
>
>
> #define PFERR_PRESENT_BIT 0
> diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
> index 5a3022c8af82..b0f9945067f7 100644
> --- a/arch/x86/include/uapi/asm/kvm.h
> +++ b/arch/x86/include/uapi/asm/kvm.h
> @@ -282,6 +282,7 @@ struct kvm_debug_exit_arch {
> #define KVM_GUESTDBG_USE_HW_BP 0x00020000
> #define KVM_GUESTDBG_INJECT_DB 0x00040000
> #define KVM_GUESTDBG_INJECT_BP 0x00080000
> +#define KVM_GUESTDBG_BLOCKIRQ 0x00100000
>
> /* for KVM_SET_GUEST_DEBUG */
> struct kvm_guest_debug_arch {
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 956e8e0bd6af..3627ce8fe5bb 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -8460,6 +8460,10 @@ static void inject_pending_event(struct kvm_vcpu *vcpu, bool *req_immediate_exit
> can_inject = false;
> }
>
> + /* Don't inject interrupts if the user asked to avoid doing so */
> + if (vcpu->guest_debug & KVM_GUESTDBG_BLOCKIRQ)
> + return;
> +
> /*
> * Finally, inject interrupt events. If an event cannot be injected
> * due to architectural conditions (e.g. IF=0) a window-open exit
>
next prev parent reply other threads:[~2021-04-02 17:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 13:54 [PATCH v2 0/9] KVM: my debug patch queue Maxim Levitsky
2021-04-01 13:54 ` [PATCH v2 1/9] scripts/gdb: rework lx-symbols gdb script Maxim Levitsky
2021-04-01 13:54 ` [PATCH v2 2/9] KVM: introduce KVM_CAP_SET_GUEST_DEBUG2 Maxim Levitsky
2021-04-01 13:54 ` [PATCH v2 3/9] KVM: x86: implement KVM_CAP_SET_GUEST_DEBUG2 Maxim Levitsky
2021-04-01 13:54 ` [PATCH v2 4/9] KVM: aarch64: " Maxim Levitsky
2021-04-01 13:54 ` [PATCH v2 5/9] KVM: s390x: " Maxim Levitsky
2021-04-01 13:54 ` [PATCH v2 6/9] KVM: x86: implement KVM_GUESTDBG_BLOCKEVENTS Maxim Levitsky
2021-04-02 17:07 ` Paolo Bonzini [this message]
2021-04-01 13:54 ` [PATCH v2 7/9] KVM: SVM: split svm_handle_invalid_exit Maxim Levitsky
2021-04-01 13:54 ` [PATCH v2 8/9] KVM: x86: add force_intercept_exceptions_mask Maxim Levitsky
2021-04-27 11:38 ` Borislav Petkov
2021-04-01 13:54 ` [PATCH v2 9/9] KVM: SVM: implement force_intercept_exceptions_mask Maxim Levitsky
2021-04-02 17:38 ` [PATCH v2 0/9] KVM: my debug patch queue Paolo Bonzini
2021-04-06 11:59 ` Maxim Levitsky
2021-04-26 12:43 ` Maxim Levitsky
2021-04-26 12:55 ` Paolo Bonzini
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=f9e1ca0c-d6cb-7477-55f2-c4861d8f8704@redhat.com \
--to=pbonzini@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=borntraeger@de.ibm.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=cohuck@redhat.com \
--cc=corbet@lwn.net \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=imbrenda@linux.ibm.com \
--cc=james.morse@arm.com \
--cc=jan.kiszka@siemens.com \
--cc=jeyu@kernel.org \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=julien.thierry.kdev@gmail.com \
--cc=kbingham@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=maz@kernel.org \
--cc=mingo@redhat.com \
--cc=mlevitsk@redhat.com \
--cc=seanjc@google.com \
--cc=sgarzare@redhat.com \
--cc=suzuki.poulose@arm.com \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/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).