From: Peter Xu <peterx@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH 9/9] KVM: VMX: pass correct DR6 for GD userspace exit
Date: Thu, 7 May 2020 12:38:39 -0400 [thread overview]
Message-ID: <20200507163839.GG228260@xz-x1> (raw)
In-Reply-To: <7abe5f7b-2b5a-4e32-34e2-f37d0afef00a@redhat.com>
On Thu, May 07, 2020 at 06:21:18PM +0200, Paolo Bonzini wrote:
> On 07/05/20 18:18, Peter Xu wrote:
> >> if (vcpu->guest_debug & KVM_GUESTDBG_USE_HW_BP) {
> >> - vcpu->run->debug.arch.dr6 = vcpu->arch.dr6;
> >> + vcpu->run->debug.arch.dr6 = DR6_BD | DR6_RTM | DR6_FIXED_1;
> > After a second thought I'm thinking whether it would be okay to have BS set in
> > that test case. I just remembered there's a test case in the kvm-unit-test
> > that checks explicitly against BS leftover as long as dr6 is not cleared
> > explicitly by the guest code, while the spec seems to have no explicit
> > description on this case.
>
> Yes, I noticed that test as well. But I don't like having different
> behavior for Intel and AMD, and the Intel behavior is more sensible.
> Also...
Do you mean the AMD behavior is more sensible instead? :)
>
> > Intead of above, I'm thinking whether we should allow the userspace to also
> > change dr6 with the KVM_SET_GUEST_DEBUG ioctl when they wanted to (right now
> > iiuc dr6 from userspace is completely ignored), instead of offering a fake dr6.
> > Or to make it simple, maybe we can just check BD bit only?
>
> ... I'm afraid that this would be a backwards-incompatible change, and
> it would require changes in userspace. If you look at v2, emulating the
> Intel behavior in AMD turns out to be self-contained and relatively
> elegant (will be better when we finish cleaning up nested SVM).
I'm still trying to read the other patches (I need some more digest because I'm
even less familiar with nested...). I agree that it would be good to keep the
same behavior across Intel/AMD. Actually that also does not violate Intel spec
because the AMD one is stricter. However I guess then we might also want to
fixup the kvm-unit-test too to aligh with the behaviors on leftover set bits.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2020-05-07 16:38 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-07 11:50 [PATCH v2 0/9] KVM_SET_GUEST_DEBUG tests and fixes, DR accessors cleanups Paolo Bonzini
2020-05-07 11:50 ` [PATCH v2 1/9] KVM: X86: Declare KVM_CAP_SET_GUEST_DEBUG properly Paolo Bonzini
2020-05-07 11:50 ` [PATCH v2 2/9] KVM: x86: fix DR6 delivery for various cases of #DB injection Paolo Bonzini
2020-05-07 11:50 ` [PATCH v2 3/9] KVM: X86: Set RTM for DB_VECTOR too for KVM_EXIT_DEBUG Paolo Bonzini
2020-05-07 11:50 ` [PATCH v2 4/9] KVM: X86: Fix single-step with KVM_SET_GUEST_DEBUG Paolo Bonzini
2020-05-07 11:50 ` [PATCH v2 5/9] KVM: selftests: Add KVM_SET_GUEST_DEBUG test Paolo Bonzini
2020-05-07 11:50 ` [PATCH v2 6/9] KVM: nSVM: trap #DB and #BP to userspace if guest debugging is on Paolo Bonzini
2020-05-07 18:22 ` Peter Xu
2020-05-07 11:50 ` [PATCH v2 7/9] KVM: SVM: keep DR6 synchronized with vcpu->arch.dr6 Paolo Bonzini
2020-05-07 18:22 ` Peter Xu
2020-05-07 22:21 ` Paolo Bonzini
2020-05-07 11:50 ` [PATCH v2 8/9] KVM: x86, SVM: isolate vcpu->arch.dr6 from vmcb->save.dr6 Paolo Bonzini
2020-05-07 19:28 ` Peter Xu
2020-05-07 22:33 ` Paolo Bonzini
2020-05-08 15:32 ` Peter Xu
2020-05-09 13:28 ` Paolo Bonzini
2020-05-11 16:15 ` Peter Xu
2020-05-07 11:50 ` [PATCH 9/9] KVM: VMX: pass correct DR6 for GD userspace exit Paolo Bonzini
2020-05-07 16:18 ` Peter Xu
2020-05-07 16:21 ` Paolo Bonzini
2020-05-07 16:38 ` Peter Xu [this message]
2020-05-07 17:42 ` Paolo Bonzini
2020-05-07 18:05 ` Peter Xu
-- strict thread matches above, loose matches on Subject: below --
2020-05-06 11:10 [PATCH 0/9] KVM_SET_GUEST_DEBUG tests and fixes, DR accessors cleanups Paolo Bonzini
2020-05-06 11:10 ` [PATCH 9/9] KVM: VMX: pass correct DR6 for GD userspace exit Paolo Bonzini
2020-05-06 17:50 ` Peter Xu
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=20200507163839.GG228260@xz-x1 \
--to=peterx@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.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).