[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200511161505.GI228260@xz-x1>
Date: Mon, 11 May 2020 12:15:05 -0400
From: Peter Xu <peterx@...hat.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH v2 8/9] KVM: x86, SVM: isolate vcpu->arch.dr6 from
vmcb->save.dr6
On Sat, May 09, 2020 at 03:28:44PM +0200, Paolo Bonzini wrote:
> On 08/05/20 17:32, Peter Xu wrote:
> > On Fri, May 08, 2020 at 12:33:57AM +0200, Paolo Bonzini wrote:
> >> On 07/05/20 21:28, Peter Xu wrote:
> >>>> - svm->vcpu.arch.dr6 = dr6;
> >>>> + WARN_ON(svm->vcpu.arch.switch_db_regs & KVM_DEBUGREG_WONT_EXIT);
> >>>> + svm->vcpu.arch.dr6 &= ~(DR_TRAP_BITS | DR6_RTM);
> >>>> + svm->vcpu.arch.dr6 |= dr6 & ~DR6_FIXED_1;
> >>> I failed to figure out what the above calculation is going to do...
> >>
> >> The calculation is merging the cause of the #DB with the guest DR6.
> >> It's basically the same effect as kvm_deliver_exception_payload.
> >
> > Shall we introduce a helper for both kvm_deliver_exception_payload and here
> > (e.g. kvm_merge_dr6)? Also, wondering whether this could be a bit easier to
> > follow by defining:
>
> It would make sense indeed but I plan to get rid of this in 5.9 (so in
> about a month), as explained in the comment.
OK. I thought it would be easy to change and verify when with the selftests,
however it's definitely ok to work upon it too. Thanks,
--
Peter Xu
Powered by blists - more mailing lists