From: Gleb Natapov <gleb@redhat.com>
To: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>
Cc: Xiao Guangrong <xiaoguangrong.eric@gmail.com>,
Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>,
avi.kivity@gmail.com, mtosatti@redhat.com, pbonzini@redhat.com,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH v3 0/6] KVM: MMU: fast invalidate all mmio sptes
Date: Mon, 10 Jun 2013 20:03:41 +0300 [thread overview]
Message-ID: <20130610170341.GJ29022@redhat.com> (raw)
In-Reply-To: <20130610224352.0a769838745b294fc43f7823@gmail.com>
On Mon, Jun 10, 2013 at 10:43:52PM +0900, Takuya Yoshikawa wrote:
> On Mon, 10 Jun 2013 16:39:37 +0800
> Xiao Guangrong <xiaoguangrong.eric@gmail.com> wrote:
>
> > On 06/10/2013 03:56 PM, Gleb Natapov wrote:
> > > On Fri, Jun 07, 2013 at 04:51:22PM +0800, Xiao Guangrong wrote:
>
> > > Looks good to me, but doesn't tis obsolete kvm_mmu_zap_mmio_sptes() and
> > > sp->mmio_cached, so they should be removed as part of the patch series?
> >
> > Yes, i agree, they should be removed. :)
>
> I'm fine with removing it but please make it clear that you all agree
> on the same basis.
>
> Last time, Paolo mentioned the possibility to use some bits of spte for
> other things. The suggestion there was to keep sp->mmio_cached code
> for the time we would need to reduce the bits for generation numbers.
>
> Do you think that zap_all() is now preemptible and can treat the
> situation reasonably well as the current kvm_mmu_zap_mmio_sptes()?
>
> One downside is the need to zap unrelated shadow pages, but if this case
> is really very rare, yes I agree, it should not be a problem: it depends
> on how many bits we can use.
>
> Just please reconfirm.
>
That was me who mention the possibility to use some bits of spte for
other things. But for now I have a use for one bit only. Now that you
have reminded me about that discussion I am not so sure we want to
remove kvm_mmu_zap_mmio_sptes(), but on the other hand it is non
preemptable, so large number of mmio sptes can cause soft lockups.
zap_all() is better in this regards now.
--
Gleb.
next prev parent reply other threads:[~2013-06-10 17:03 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-07 8:51 [PATCH v3 0/6] KVM: MMU: fast invalidate all mmio sptes Xiao Guangrong
2013-06-07 8:51 ` [PATCH v3 1/6] KVM: MMU: retain more available bits on mmio spte Xiao Guangrong
2013-06-07 8:51 ` [PATCH v3 2/6] KVM: MMU: store generation-number into " Xiao Guangrong
2013-06-07 8:51 ` [PATCH v3 3/6] KVM: MMU: make return value of mmio page fault handler more readable Xiao Guangrong
2013-06-10 7:57 ` Gleb Natapov
2013-06-10 8:45 ` Xiao Guangrong
2013-06-10 13:16 ` Takuya Yoshikawa
2013-06-11 9:18 ` Gleb Natapov
2013-06-07 8:51 ` [PATCH v3 4/6] KVM: MMU: fast invalidate all mmio sptes Xiao Guangrong
2013-06-27 8:29 ` Gleb Natapov
2013-06-27 9:01 ` Gleb Natapov
2013-06-27 9:14 ` Gleb Natapov
2013-06-27 9:21 ` Gleb Natapov
2013-06-27 9:50 ` Xiao Guangrong
2013-06-27 10:19 ` Gleb Natapov
2013-06-27 11:05 ` Xiao Guangrong
2013-06-27 11:10 ` Gleb Natapov
2013-06-07 8:51 ` [PATCH v3 5/6] KVM: MMU: add tracepoint for check_mmio_spte Xiao Guangrong
2013-06-07 8:51 ` [PATCH v3 6/6] KVM: MMU: init kvm generation close to mmio wrap-around value Xiao Guangrong
2013-06-10 7:56 ` [PATCH v3 0/6] KVM: MMU: fast invalidate all mmio sptes Gleb Natapov
2013-06-10 8:39 ` Xiao Guangrong
2013-06-10 13:43 ` Takuya Yoshikawa
2013-06-10 17:03 ` Gleb Natapov [this message]
2013-06-19 11:08 ` Paolo Bonzini
2013-06-19 11:27 ` Xiao Guangrong
2013-06-14 0:08 ` Marcelo Tosatti
2013-06-15 2:22 ` Takuya Yoshikawa
2013-06-17 11:59 ` Xiao Guangrong
2013-06-18 22:21 ` Marcelo Tosatti
2013-06-18 14:26 ` Paolo Bonzini
2013-06-19 2:47 ` Xiao Guangrong
2013-06-19 17:40 ` Paolo Bonzini
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=20130610170341.GJ29022@redhat.com \
--to=gleb@redhat.com \
--cc=avi.kivity@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=takuya.yoshikawa@gmail.com \
--cc=xiaoguangrong.eric@gmail.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.