All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: gleb@redhat.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH v2 0/6] KVM: MMU: fast invalid all mmio sptes
Date: Tue, 16 Apr 2013 11:09:37 +0800	[thread overview]
Message-ID: <516CC0F1.30404@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130416005439.GC1962@amt.cnet>


Hi Marcelo,

On 04/16/2013 08:54 AM, Marcelo Tosatti wrote:
> On Mon, Apr 01, 2013 at 05:56:43PM +0800, Xiao Guangrong wrote:
>> Changelog in v2:
>>   - rename kvm_mmu_invalid_mmio_spte to kvm_mmu_invalid_mmio_sptes
>>   - use kvm->memslots->generation as kvm global generation-number
>>   - fix comment and codestyle
>>   - init kvm generation close to mmio wrap-around value
>>   - keep kvm_mmu_zap_mmio_sptes
>>
>> The current way is holding hot mmu-lock and walking all shadow pages, this
>> is not scale. This patchset tries to introduce a very simple and scale way
>> to fast invalid all mmio sptes - it need not walk any shadow pages and hold
>> any locks.
>>
>> The idea is simple:
>> KVM maintains a global mmio invalid generation-number which is stored in
>> kvm->memslots.generation and every mmio spte stores the current global
>> generation-number into his available bits when it is created
>>
>> When KVM need zap all mmio sptes, it just simply increase the global
>> generation-number. When guests do mmio access, KVM intercepts a MMIO #PF
>> then it walks the shadow page table and get the mmio spte. If the
>> generation-number on the spte does not equal the global generation-number,
>> it will go to the normal #PF handler to update the mmio spte
>>
>> Since 19 bits are used to store generation-number on mmio spte, we zap all
>> mmio sptes when the number is round
> 
> Hi Xiao,
> 
> Is it still necessary with generation numbers at 'struct shadow_page'
> level (which covers the slot deletion case).

Yes.

> 
> That is, once kvm_mmu_zap_all is fixed to increase generation count and
> nuke roots, can't that be used instead with similar effectiveness for
> SLOT_CREATE/SLOT_MOVE cases?

It seems not easy. :(

We can not increase kvm's generation count for SLOT_CREATE since any change
on kvm->generation_count will cause all vcpus fault on _all_ memory region.

We also can not separately update mmio-sp's generation count instead of
zapping them since a sp can have both mmio-spte and normal-spte, we should
zap the normal spte on a mmio-sp.

Thanks!

      reply	other threads:[~2013-04-16  3:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-01  9:56 [PATCH v2 0/6] KVM: MMU: fast invalid all mmio sptes Xiao Guangrong
2013-04-01  9:56 ` [PATCH v2 1/6] KVM: MMU: retain more available bits on mmio spte Xiao Guangrong
2013-04-01  9:56 ` [PATCH v2 2/6] KVM: MMU: store generation-number into " Xiao Guangrong
2013-04-01  9:56 ` [PATCH v2 3/6] KVM: MMU: make return value of mmio page fault handler more readable Xiao Guangrong
2013-04-24 13:34   ` Gleb Natapov
2013-04-25  9:24     ` Xiao Guangrong
2013-04-01  9:56 ` [PATCH v2 4/6] KVM: MMU: fast invalid all mmio sptes Xiao Guangrong
2013-04-01  9:56 ` [PATCH v2 5/6] KVM: MMU: add tracepoint for check_mmio_spte Xiao Guangrong
2013-04-01  9:56 ` [PATCH v2 6/6] KVM: MMU: init kvm generation close to mmio wrap-around value Xiao Guangrong
2013-04-24 12:59   ` Gleb Natapov
2013-04-25  9:23     ` Xiao Guangrong
2013-04-16  0:54 ` [PATCH v2 0/6] KVM: MMU: fast invalid all mmio sptes Marcelo Tosatti
2013-04-16  3:09   ` Xiao Guangrong [this message]

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=516CC0F1.30404@linux.vnet.ibm.com \
    --to=xiaoguangrong@linux.vnet.ibm.com \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@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.