All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xiaoyao Li <xiaoyao.li@intel.com>
To: Peter Xu <peterx@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>,
	kvm@vger.kernel.org, Nadav Amit <namit@cs.technion.ac.il>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/3] kvm: x86: Rename KVM_DEBUGREG_RELOAD to KVM_DEBUGREG_NEED_RELOAD
Date: Tue, 28 Apr 2020 00:06:20 +0800	[thread overview]
Message-ID: <3cc6471b-13da-832f-18d8-6db840b5ac47@intel.com> (raw)
In-Reply-To: <20200427143732.GD48376@xz-x1>

On 4/27/2020 10:37 PM, Peter Xu wrote:
> On Sat, Apr 25, 2020 at 09:48:17AM +0200, Paolo Bonzini wrote:
>> On 24/04/20 22:21, Peter Xu wrote:
>>> But then shouldn't DIRTY be set as long as KVM_DEBUGREG_BP_ENABLED is set every
>>> time before vmenter?  Then it'll somehow go back to switch_db_regs, iiuc...
>>>
>>> IIUC RELOAD actually wants to say "reload only for this iteration", that's why
>>> it's cleared after each reload.  So maybe...  RELOAD_ONCE?
>>>
>>> (Btw, do we have debug regs tests somewhere no matter inside guest or with
>>>   KVM_SET_GUEST_DEBUG?)
>>
>> What about KVM_DEBUGREG_EFF_DB_DIRTY?
> 
> The problem is iiuc we always reload eff_db[] no matter which bit in
> switch_db_regs is set, so this may still not clearly identify this bit from the
> rest of the two bits...
> 
> Actually I think eff_db[] is a bit confusing here in that it can be either the
> host specified dbreg values or the guest specified depends on the dynamic value
> of KVM_GUESTDBG_USE_HW_BP.
> 
> I am thinking maybe it's clearer to have host_db[] and guest_db[], then only
> until vmenter do we load either of them by:

host_db[] is somewhat misleading, how about user_db[] (just like user_fpu)

>    if (KVM_GUESTDBG_USE_HW_BP)
>      load(host_db[]);
>    else
>      load(gueet_db[]);
> 
> Then each db[] will be very clear on what's the data is about.  And we don't
> need to check KVM_GUESTDBG_USE_HW_BP every time when accessing eff_db[].
> 


  reply	other threads:[~2020-04-27 16:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-16 10:15 [RFC PATCH 0/3] kvm: x86: Cleanup and optimazation of switch_db_regs Xiaoyao Li
2020-04-16 10:15 ` [RFC PATCH 1/3] kvm: x86: Rename KVM_DEBUGREG_RELOAD to KVM_DEBUGREG_NEED_RELOAD Xiaoyao Li
2020-04-23 19:09   ` Sean Christopherson
2020-04-24 13:28     ` Xiaoyao Li
2020-04-24 20:21     ` Peter Xu
2020-04-24 20:29       ` Sean Christopherson
2020-04-24 20:59         ` Peter Xu
2020-04-25  7:48       ` Paolo Bonzini
2020-04-27 14:37         ` Peter Xu
2020-04-27 16:06           ` Xiaoyao Li [this message]
2020-04-25  8:07   ` Paolo Bonzini
2020-04-25 16:54     ` Nadav Amit
2020-04-25 19:16       ` Paolo Bonzini
2020-04-16 10:15 ` [RFC PATCH 2/3] kvm: x86: Use KVM_DEBUGREG_NEED_RELOAD instead of KVM_DEBUGREG_BP_ENABLED Xiaoyao Li
2020-04-23 19:29   ` Sean Christopherson
2020-04-24 13:21     ` Xiaoyao Li
2020-04-16 10:15 ` [RFC PATCH 3/3] kvm: x86: skip DRn reload if previous VM exit is DR access VM exit Xiaoyao Li
2020-04-23 19:31   ` 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=3cc6471b-13da-832f-18d8-6db840b5ac47@intel.com \
    --to=xiaoyao.li@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namit@cs.technion.ac.il \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=vkuznets@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.