On 09/09/2010 04:03 AM, Liu Yu-B13201 wrote:
-----Original Message-----
From: kvm-ppc-owner@xxxxxxxxxxxxxxx
[mailto:kvm-ppc-owner@xxxxxxxxxxxxxxx] On Behalf Of Hollis Blanchard
Sent: Thursday, September 09, 2010 12:07 AM
To: Liu Yu-B13201
Cc: kvm@xxxxxxxxxxxxxxx; kvm-ppc@xxxxxxxxxxxxxxx; agraf@xxxxxxx
Subject: Re: [PATCH 0/2] kvm/e500v2: MMU optimization
On 09/08/2010 02:40 AM, Liu Yu wrote:
The patchset aims at mapping guest TLB1 to host TLB0.
And it includes:
[PATCH 1/2] kvm/e500v2: Remove shadow tlb
[PATCH 2/2] kvm/e500v2: mapping guest TLB1 to host TLB0
The reason we need patch 1 is because patch 1 make things
simple and flexible.
Only applying patch 1 aslo make kvm work.
I've always thought the best long-term "optimization" on
these cores is
to share in the host PID allocation (i.e. __init_new_context()). This
way, the TID in guest mappings would not overlap the TID in host
mappings, and guest mappings could be demand-faulted rather
than swapped
wholesale. To do that, you would need to track the host PID
in KVM data
structures, I guess in the tlbe_ref structure.
Hi Hollis,
Guest uses AS=1 and host uses AS=0,
so even guest uses the same TID with host, they're in different space.
Then why guest needs to care about host TID?
You're absolutely right, but this makes a couple key assumptions:
1. The guest doesn't try to use AS=1. This is already false in Linux,
because the udbg code uses an AS=1 mapping for the UART, but this can be
configured out (with a small loss in functionality). In non-Linux guests
the AS=0 restriction could be onerous.
2. A Book E MMU. If we participate in the host "MMU context" allocation,
the guest -> host address space code could be generalized to include
e.g. an e600 guest on an e500 host, or vice versa.
So you're right that "optimization" is not the right word; this would be
more of a functionality and design improvement. (In fact, I suppose it
could reduce performance on Book E, since AS=1 space actually *is*
unused by the host. I think it would be worth finding out.)
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
