From: Alexey Kardashevskiy <aik@amd.com>
To: Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org,
Tom Lendacky <thomas.lendacky@amd.com>,
Pankaj Gupta <pankaj.gupta@amd.com>,
Nikunj A Dadhania <nikunj@amd.com>,
Santosh Shukla <santosh.shukla@amd.com>,
Carlos Bilbao <carlos.bilbao@amd.com>
Subject: Re: [PATCH kernel v5 5/6] KVM: SEV: Enable data breakpoints in SEV-ES
Date: Tue, 30 May 2023 18:57:46 +1000 [thread overview]
Message-ID: <64336829-60c5-afe1-81ad-91b4f354aef3@amd.com> (raw)
In-Reply-To: <ZHDEkuaVjs/0kM6t@google.com>
On 27/5/23 00:39, Sean Christopherson wrote:
> On Fri, May 26, 2023, Alexey Kardashevskiy wrote:
>>
>> On 24/5/23 01:44, Sean Christopherson wrote:
>>> On Tue, May 23, 2023, Alexey Kardashevskiy wrote:
>>>>> Actually, can't disabling #DB interception for DebugSwap SEV-ES guests be a
>>>>> separate patch? KVM can still inject #DBs for SEV-ES guests, no?
>>>>
>>>> Sorry for my ignorance but what is the point of injecting #DB if there is no
>>>> way of changing the guest's DR7?
>>>
>>> Well, _injecting_ the #DB is necessary for correctness from the guest's perspective.
>>> "What's the point of _intercepting_ #DB" is the real question. And for SEV-ES guests
>>> with DebugSwap, there is no point, which is why I agree that KVM should disable
>>> interception in that case. What I'm calling out is that disabling #Db interception
>>> isn't _necessary_ for correctness (unless I'm missing something), which means that
>>> it can and should go in a separate patch.
>>
>>
>> About this. Instead of sev_es_init_vmcb(), I can toggle the #DB intercept
>> when toggling guest_debug, see below. This
>> kvm_x86_ops::update_exception_bitmap hook is called on vcpu reset and
>> kvm_arch_vcpu_ioctl_set_guest_debug (which skips this call if
>> guest_state_protected = true).
>
> KVM also intercepts #DB when single-stepping over IRET to find an NMI window, so
> you'd also have to factor in nmi_singlestep, and update svm_enable_nmi_window()
> and disable_nmi_singlestep() to call svm_update_exception_bitmap().
Uff. New can of worms for me :-/
>> Is there any downside?
>
> Complexity is the main one. The complexity is quite low, but the benefit to the
> guest is likely even lower. A #DB in the guest isn't likely to be performance
> sensitive. And on the flip side, opening an NMI window would be a tiny bit more
> expensive, though I doubt that would be meaningful either.
>
> All in all, I think it makes sense to just keep intercepting #DB for non-SEV-ES
> guests.
>
> Side topic, isn't there an existing bug regarding SEV-ES NMI windows? KVM can't
> actually single-step an SEV-ES guest, but tries to set RFLAGS.TF anyways.
Why is it a "bug" and what does the patch fix? Sound to me as it is
pointless and the guest won't do single stepping and instead will run
till it exits somehow, what do I miss?
> Blech,
> and suppressing EFER.SVME in efer_trap() is a bit gross,
Why suppressed? svm_set_efer() sets it eventually anyway.
> but I suppose since the
> GHCB doesn't allow for CLGI or STGI it's "fine".
GHCB does not mention this, instead these are always intercepted in
init_vmcb().
> E.g. shouldn't KVM do this?
It sure can and I am happy to include this into the series, the commit
log is what I am struggling with :)
>
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index ca32389f3c36..4e4a49031efe 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -3784,6 +3784,16 @@ static void svm_enable_nmi_window(struct kvm_vcpu *vcpu)
> if (svm_get_nmi_mask(vcpu) && !svm->awaiting_iret_completion)
> return; /* IRET will cause a vm exit */
>
> + /*
> + * KVM can't single-step SEV-ES guests and instead assumes that IRET
> + * in the guest will always succeed,
It relies on GHCB's NMI_COMPLETE (which SVM than handles is it was IRET):
case SVM_VMGEXIT_NMI_COMPLETE:
ret = svm_invoke_exit_handler(vcpu, SVM_EXIT_IRET);
break;
> i.e. clears NMI masking on the
> + * next VM-Exit. Note, GIF is guaranteed to be '1' for SEV-ES guests
> + * as the GHCB doesn't allow for CLGI or STGI (and KVM suppresses
> + * EFER.SVME for good measure, see efer_trap()).
SVM KVM seems to not enforce EFER.SVME, the guest does what it wants and
KVM is only told the new value via EFER_WRITE_TRAP. And "writes by
SEV-ES guests to EFER.SVME are always ignored by hardware" says the APM.
I must be missing the point here...
> + */
> + if (sev_es_guest(vcpu->kvm))
> + return;
> +
> if (!gif_set(svm)) {
> if (vgif)
> svm_set_intercept(svm, INTERCEPT_STGI);
--
Alexey
next prev parent reply other threads:[~2023-05-30 8:58 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-11 12:57 [PATCH kernel v5 0/6] KVM: SEV: Enable AMD SEV-ES DebugSwap Alexey Kardashevskiy
2023-04-11 12:57 ` [PATCH kernel v5 1/6] KVM: SEV: move set_dr_intercepts/clr_dr_intercepts from the header Alexey Kardashevskiy
2023-04-11 12:57 ` [PATCH kernel v5 2/6] KVM: SEV: Move SEV's GP_VECTOR intercept setup to SEV Alexey Kardashevskiy
2023-04-11 12:57 ` [PATCH kernel v5 3/6] KVM: SEV-ES: explicitly disable debug Alexey Kardashevskiy
2023-05-22 22:50 ` Sean Christopherson
2023-04-11 12:57 ` [PATCH kernel v5 4/6] KVM: SVM/SEV/SEV-ES: Rework intercepts Alexey Kardashevskiy
2023-05-22 22:53 ` Sean Christopherson
2023-04-11 12:57 ` [PATCH kernel v5 5/6] KVM: SEV: Enable data breakpoints in SEV-ES Alexey Kardashevskiy
2023-05-09 10:58 ` Gupta, Pankaj
2023-05-10 9:35 ` Gupta, Pankaj
2023-05-22 23:39 ` Sean Christopherson
2023-05-23 11:33 ` Alexey Kardashevskiy
2023-05-23 15:44 ` Sean Christopherson
2023-05-26 3:16 ` Alexey Kardashevskiy
2023-05-26 14:39 ` Sean Christopherson
2023-05-30 8:57 ` Alexey Kardashevskiy [this message]
2023-06-01 23:31 ` Alexey Kardashevskiy
2023-06-13 23:19 ` Sean Christopherson
2023-06-14 3:58 ` Alexey Kardashevskiy
2023-06-14 21:27 ` Sean Christopherson
2023-04-11 12:57 ` [PATCH kernel v5 6/6] x86/sev: Do not handle #VC for DR7 read/write Alexey Kardashevskiy
2023-05-22 23:44 ` Sean Christopherson
2023-05-24 6:36 ` Alexey Kardashevskiy
2023-04-20 1:49 ` [PATCH kernel v5 0/6] KVM: SEV: Enable AMD SEV-ES DebugSwap Alexey Kardashevskiy
2023-04-20 14:32 ` Sean Christopherson
2023-05-19 0:19 ` Alexey Kardashevskiy
2023-05-19 15:28 ` Sean Christopherson
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=64336829-60c5-afe1-81ad-91b4f354aef3@amd.com \
--to=aik@amd.com \
--cc=carlos.bilbao@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nikunj@amd.com \
--cc=pankaj.gupta@amd.com \
--cc=santosh.shukla@amd.com \
--cc=seanjc@google.com \
--cc=thomas.lendacky@amd.com \
--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
all inboxes | Powered by JetHome®