From: Ingo Molnar <mingo@elte.hu>
To: Avi Kivity <avi@qumranet.com>
Cc: kvm-devel <kvm-devel@lists.sourceforge.net>,
linux-kernel@vger.kernel.org
Subject: Re: [announce] [patch] KVM paravirtualization for Linux
Date: Mon, 8 Jan 2007 09:39:35 +0100 [thread overview]
Message-ID: <20070108083935.GB18259@elte.hu> (raw)
In-Reply-To: <45A1FF4E.1020106@qumranet.com>
* Avi Kivity <avi@qumranet.com> wrote:
> > the cache is zapped upon pagefaults anyway, so unpinning ought to be
> > possible. Which one would you prefer?
>
> It's zapped by the equivalent of mmu_free_roots(), right? That's
> effectively unpinning it (by zeroing ->root_count).
no, right now only the guest-visible cache is zapped - the roots are
zapped by natural rotation. I guess they should be zapped in
kvm_cr3_cache_clear() - but i wanted to keep that function an invariant
to the other MMU state, to make it easier to call it from whatever mmu
codepath.
> However, kvm takes pagefaults even for silly things like setting (in
> hardware) or clearing (in software) the dirty bit.
yeah. I think it also does some TLB flushes that are not needed. For
example in rmap_write_protect() we do this:
rmap_remove(vcpu, spte);
kvm_arch_ops->tlb_flush(vcpu);
but AFAICS rmap_write_protect() is only ever called if we write a new
cr3 - hence a TLB flush will happen anyway, because we do a
vmcs_writel(GUEST_CR3, new_cr3). Am i missing something? I didnt want to
remove it as part of the cr3 patches (to keep things simpler), but that
flush looks quite unnecessary to me. The patch below seems to work in
light testing.
Ingo
Index: linux/drivers/kvm/mmu.c
===================================================================
--- linux.orig/drivers/kvm/mmu.c
+++ linux/drivers/kvm/mmu.c
@@ -404,7 +404,11 @@ static void rmap_write_protect(struct kv
BUG_ON(!(*spte & PT_WRITABLE_MASK));
rmap_printk("rmap_write_protect: spte %p %llx\n", spte, *spte);
rmap_remove(vcpu, spte);
- kvm_arch_ops->tlb_flush(vcpu);
+ /*
+ * While we removed a mapping there's no need to explicitly
+ * flush the TLB here, because this codepath only triggers
+ * if we write a new cr3 - which will flush the TLB anyway.
+ */
*spte &= ~(u64)PT_WRITABLE_MASK;
}
}
next prev parent reply other threads:[~2007-01-08 8:42 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-05 21:52 [announce] [patch] KVM paravirtualization for Linux Ingo Molnar
2007-01-05 22:15 ` Zachary Amsden
2007-01-05 22:30 ` Ingo Molnar
2007-01-05 22:50 ` Zachary Amsden
2007-01-05 23:28 ` Ingo Molnar
2007-01-05 23:02 ` [kvm-devel] " Anthony Liguori
2007-01-06 13:08 ` Pavel Machek
2007-01-07 18:29 ` Christoph Hellwig
2007-01-08 18:18 ` Christoph Lameter
2007-01-07 12:20 ` Avi Kivity
2007-01-07 17:42 ` [kvm-devel] " Hollis Blanchard
2007-01-07 17:44 ` Ingo Molnar
2007-01-08 8:22 ` Avi Kivity
2007-01-08 8:39 ` Ingo Molnar [this message]
2007-01-08 9:08 ` Avi Kivity
2007-01-08 9:18 ` Ingo Molnar
2007-01-08 9:31 ` Avi Kivity
2007-01-08 9:43 ` Ingo Molnar
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=20070108083935.GB18259@elte.hu \
--to=mingo@elte.hu \
--cc=avi@qumranet.com \
--cc=kvm-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox