All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@kernel.org>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: kvm@vger.kernel.org, ak@linux.intel.com, pbonzini@redhat.com,
	xiaoguangrong@linux.vnet.ibm.com, avi.kivity@gmail.com
Subject: Re: [patch 3/4] KVM: MMU: reload request from GET_DIRTY_LOG path
Date: Wed, 15 Oct 2014 11:03:54 +0300	[thread overview]
Message-ID: <20141015080353.GX26540@minantech.com> (raw)
In-Reply-To: <20141013085238.GB6957@amt.cnet>

On Mon, Oct 13, 2014 at 05:52:38AM -0300, Marcelo Tosatti wrote:
> On Fri, Oct 10, 2014 at 04:09:29PM +0300, Gleb Natapov wrote:
> > On Wed, Oct 08, 2014 at 04:22:31PM -0300, Marcelo Tosatti wrote:
> > > > > 
> > > > > Argh, lets try again:
> > > > > 
> > > > > skip_pinned = true
> > > > > ------------------
> > > > > 
> > > > > mark page dirty, keep spte intact
> > > > > 
> > > > > called from get dirty log path.
> > > > > 
> > > > > skip_pinned = false
> > > > > -------------------
> > > > > reload remote mmu
> > > > > destroy pinned spte.
> > > > > 
> > > > > called from: dirty log enablement, rmap write protect (unused for pinned
> > > > > sptes)
> > > > > 
> > > > > 
> > > > > Note this behaviour is your suggestion:
> > > > 
> > > > Yes, I remember that and I thought we will not need this skip_pinned
> > > > at all.  For rmap write protect case there shouldn't be any pinned pages,
> > > > but why dirty log enablement sets skip_pinned to false? Why not mark
> > > > pinned pages as dirty just like you do in get dirty log path?
> > > 
> > > Because if its a large spte, it must be nuked (or marked read-only,
> > > which for pinned sptes, is not possible).
> > > 
> > If a large page has one small page pinned inside it its spte will
> > be marked as pinned, correct?  
> 
> Correct.
> 
> > We did nuke large ptes here until very
> > recently: c126d94f2c90ed9d, but we cannot drop a pte here anyway without
> > kicking all vcpu from a guest mode, but do you need additional skip_pinned
> > parameter?  Why not check if spte is large instead?
> 
> Nuke only if large spte is found? Can do that, instead.
> 
> > So why not have per slot pinned page list (Xiao suggested the same) and do:
> 
> The interface is per-vcpu (that is registration of pinned pages is
> performed on a per-vcpu basis).
> 
PEBS is per cpu, but it does not mean that pinning should be per cpu, it
can be done globally with ref counting.

> > spte_write_protect() {
> >   if (is_pinned(spte) {
> >     if (large(spte))
> >        // cannot drop while vcpu are running
> >        mmu_reload_pinned_vcpus();
> >     else
> >        return false;
> > }
> >     
> > 
> > get_dirty_log() {
> >  for_each(pinned pages i)
> >     makr_dirty(i);
> > }
> 
> That is effectively the same this patchset does, except that the spte
> pinned bit is checked at spte_write_protect, instead of looping over 
> page pinned list. Fail to see huge advantage there.
>
I think spte_write_protect is a strange place to mark pages dirty, but
otherwise yes the effect is the same, so definitely not a huge difference.
If global pinned list is a PITA in your opinion leave it as is.

> I'll drop the skip_pinned parameter and use is_large_pte check instead.
> 
Thanks,

--
			Gleb.

  reply	other threads:[~2014-10-15  8:04 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-09 19:12 [patch 0/4] KVM: support for pinning sptes (v2) mtosatti
2014-07-09 19:12 ` [patch 1/4] KVM: x86: add pinned parameter to page_fault methods mtosatti
2014-07-09 19:12 ` [patch 2/4] KVM: MMU: allow pinning spte translations (TDP-only) mtosatti
2014-07-17 17:18   ` Nadav Amit
2014-07-17 21:38     ` Marcelo Tosatti
2014-07-24 12:16       ` Nadav Amit
2014-07-21 21:46   ` Xiao Guangrong
2014-07-22  5:26     ` Xiao Guangrong
2014-07-09 19:12 ` [patch 3/4] KVM: MMU: reload request from GET_DIRTY_LOG path mtosatti
2014-07-21 13:14   ` Gleb Natapov
2014-09-09 15:28     ` Marcelo Tosatti
2014-09-22 17:19       ` Marcelo Tosatti
2014-09-30 18:59         ` Marcelo Tosatti
2014-10-04  7:23       ` Gleb Natapov
2014-10-06 17:19         ` Marcelo Tosatti
2014-10-08  6:56           ` Gleb Natapov
2014-10-08 17:15             ` Marcelo Tosatti
2014-10-08 17:59               ` Gleb Natapov
2014-10-08 19:22                 ` Marcelo Tosatti
2014-10-10 13:09                   ` Gleb Natapov
2014-10-13  8:52                     ` Marcelo Tosatti
2014-10-15  8:03                       ` Gleb Natapov [this message]
2014-07-21 21:55   ` Xiao Guangrong
2014-09-09 15:35     ` Marcelo Tosatti
2014-07-09 19:12 ` [patch 4/4] KVM: MMU: pinned sps are not candidates for deletion mtosatti
2014-07-21 21:59   ` Xiao Guangrong
2014-09-09 15:41     ` Marcelo Tosatti
2014-09-22 17:17       ` Marcelo Tosatti
2014-09-23  5:30       ` Xiao Guangrong
2014-07-09 19:20 ` [patch 0/4] KVM: support for pinning sptes (v2) Marcelo Tosatti

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=20141015080353.GX26540@minantech.com \
    --to=gleb@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=avi.kivity@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=xiaoguangrong@linux.vnet.ibm.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.