From: Avi Kivity <avi@redhat.com>
To: Eric Northup <digitaleric@google.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH RFC] KVM MMU: fix hashing for TDP and non-paging modes
Date: Fri, 23 Apr 2010 14:11:02 +0300 [thread overview]
Message-ID: <4BD18046.8020905@redhat.com> (raw)
In-Reply-To: <l2nc35a268d1004221415n8b79b6fqafb73478aa87acf2@mail.gmail.com>
On 04/23/2010 12:15 AM, Eric Northup wrote:
> I've been reading the x86's mmu.c recently and had been wondering
> about something. Avi's recent mmu documentation (thanks!) seems to
> have confirmed my understanding of how the shadow paging is supposed
> to be working.
Wasn't it a lot more fun to understand it from the code? reading the
documentation is way to easy.
> In TDP mode, when mmu_alloc_roots() calls
> kvm_mmu_get_page(), why does it pass (vcpu->arch.cr3>> PAGE_SHIFT) or
> (vcpu->arch.mmu.pae_root[i]) as gfn?
>
Historical accident. Luckily, no harmful effects other than wasting a
bit of cpu cycles every now and then.
> It seems to me that in TDP mode, gfn should be either zero for the
> root page table, or 0/1GB/2GB/3GB (for PAE page tables).
>
> The existing behavior can lead to multiple, semantically-identical TDP
> roots being created by mmu_alloc_roots, depending on the VCPU's CR3 at
> the time that mmu_alloc_roots was called. But the nested page tables
> should be* independent of the VCPU state. That wastes some memory and
> causes extra page faults while populating the extra copies of the page
> tables.
>
Yeah.
> *assuming that we aren't modeling per-VCPU state that might change the
> physical address map as seen by that VCPU, such as setting the APIC
> base to an address overlapping RAM.
>
We don't actually support that.
> All feedback would be welcome, since I'm new to this system! A
> strawman patch follows.
>
>
Patch is correct, but I have already fixed this in a more extensive
patch set (that also folds the 32-bit and 64-bit cases together, etc.)
and I'm too lazy to rebase on top of yours.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
next prev parent reply other threads:[~2010-04-23 11:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-22 21:15 [PATCH RFC] KVM MMU: fix hashing for TDP and non-paging modes Eric Northup
2010-04-23 11:11 ` Avi Kivity [this message]
2010-04-26 9:24 ` Avi Kivity
2010-04-26 21:30 ` Marcelo Tosatti
2010-04-26 21:46 ` Marcelo Tosatti
2010-04-27 0:00 ` Eric Northup
2010-04-27 12:31 ` 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=4BD18046.8020905@redhat.com \
--to=avi@redhat.com \
--cc=digitaleric@google.com \
--cc=kvm@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 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.