RE: [PATCH 0/2] kvm/e500v2: MMU optimization
-Original Message- From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Hollis Blanchard Sent: Thursday, September 09, 2010 12:07 AM To: Liu Yu-B13201 Cc: k...@vger.kernel.org; kvm-ppc@vger.kernel.org; ag...@suse.de 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? Thanks, Yu -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] kvm/e500v2: MMU optimization
On 09/09/2010 04:03 AM, Liu Yu-B13201 wrote: -Original Message- From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Hollis Blanchard Sent: Thursday, September 09, 2010 12:07 AM To: Liu Yu-B13201 Cc: k...@vger.kernel.org; kvm-ppc@vger.kernel.org; ag...@suse.de 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-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2] kvm/e500v2: MMU optimization
-Original Message- From: Hollis Blanchard [mailto:hollis_blanch...@mentor.com] Sent: Friday, September 10, 2010 12:23 AM To: Liu Yu-B13201 Cc: k...@vger.kernel.org; kvm-ppc@vger.kernel.org; ag...@suse.de Subject: Re: [PATCH 0/2] kvm/e500v2: MMU optimization 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. We could map (guest AS, guest TID) to (shadow TID), So that we still don't need to bother host. 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. Hmm.. Not sure it's a real requirement. Thanks, Yu -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] kvm/e500v2: MMU optimization
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. -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- Hollis Blanchard Mentor Graphics, Embedded Systems Division -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
