From: Paolo Bonzini <pbonzini@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>,
Xiao Guangrong <xiaoguangrong.eric@gmail.com>,
Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>,
avi.kivity@gmail.com, mtosatti@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: Wed, 19 Jun 2013 13:08:10 +0200 [thread overview]
Message-ID: <51C1911A.3000507@redhat.com> (raw)
In-Reply-To: <20130610170341.GJ29022@redhat.com>
Il 10/06/2013 19:03, Gleb Natapov ha scritto:
> 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.
I asked Gleb on IRC, and he's fine with applying patch 7 too (otherwise
there's hardly any benefit, because kvm_mmu_zap_mmio_sptes is
non-preemptable).
I'm also changing the -13 to -150 since it's quite easy to generate 150
calls to KVM_SET_USER_MEMORY_REGION. Using QEMU, and for a pretty basic
guest with virtio-net, IDE controller and VGA you get:
- 9-10 calls before starting the guest, depending on the guest memory size
- around 25 during the BIOS
- around 20 during kernel boot
- 34 during a single dump of the 64 KB ROM from a virtio-net device.
Paolo
next prev parent reply other threads:[~2013-06-19 11:08 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
2013-06-19 11:08 ` Paolo Bonzini [this message]
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=51C1911A.3000507@redhat.com \
--to=pbonzini@redhat.com \
--cc=avi.kivity@gmail.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@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.