Re: [PATCH 0/2] kvm/e500v2: MMU optimization

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux