e500 shadow_ref
Hi guys,
As you know kvmppc uses shadow_ref to record connections between gtlbes and
pages.
44x implement it as kvmppc_44x_shadow_ref, and e500 implement it as
kvmppc_e500_shadow_ref in recent patches.
The problem for e500 now is that, the shadow_ref for TLB0 doesn't reflect the
hardware situation
but has one-one mappings to guest TLB0 entries.
This doesn't sounds logic, and make me hard to try new things, such as redirect
guest TLB1 to host TLB0, large guest TLB,
44x is fine for kvmppc_44x_shadow_ref reflects the hardware.
So I'm thinking about seperating kvmppc_e500_shadow_ref from guest TLB0 and
connect it with hardware.
Then I notice both 44x and e500 implement shadow_ref as per-vcpu data.
Can shadow_ref be per-core data?
This looks like could save some memory.
I don't want to do the wrong thing at the first step, so any suggestion?
Best Regards.
Yu
N�r��yb�X��ǧv�^�){.n�+jir)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
Re: qemu-kvm.git now live
On Thu, 2009-04-23 at 18:40 +0300, Avi Kivity wrote: Still missing: - I have not tested powerpc or ia64. Patches welcome! This repository seems pretty messed up; I'm not even sure what you want from me. Some of the bigger problems: * configure completely ignores --kerneldir and only uses kvm/kernel headers instead. * The headers in kvm/kernel/arch/foo seem to be the important ones, but they have odd ifdefs at the top and I'm not sure how they should be generated. * make -C kvm/kernel sync doesn't even come close to working. There are a host of other issues and confusing issues, even with a fresh checkout. In general it seems like the mess that was kvm-userspace has been rearranged, and as a consequence is even worse than before. How am I supposed to create kvm/kernel/arch/powerpc/include/asm/*? Just cp from a Linux tree, or must I add funny ifdefs somehow? Here's one patch that I think will be needed: Set kvm_arch=powerpc for PPC builds. The name of the Linux arch directory is powerpc, not ppc. Signed-off-by: Hollis Blanchard holl...@us.ibm.com diff --git a/configure b/configure index fc0fb9b..257cf02 100755 --- a/configure +++ b/configure @@ -816,6 +816,9 @@ case $cpu in i386 | x86_64) kvm_arch=x86 ;; +ppc) + kvm_arch=powerpc + ;; *) kvm_arch=$cpu ;; -- Hollis Blanchard IBM Linux Technology Center -- 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: qemu-kvm.git now live
Hollis Blanchard wrote: On Thu, 2009-04-23 at 18:40 +0300, Avi Kivity wrote: Still missing: - I have not tested powerpc or ia64. Patches welcome! This repository seems pretty messed up; I'm not even sure what you want from me. Since PPC is now supported in upstream QEMU, does it really matter if it works in qemu-kvm.git? Regards, Anthony Liguori -- 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: qemu-kvm.git now live
On Tue, Apr 28, 2009 at 7:20 PM, Anthony Liguori anth...@codemonkey.ws wrote: Hollis Blanchard wrote: On Thu, 2009-04-23 at 18:40 +0300, Avi Kivity wrote: Still missing: - I have not tested powerpc or ia64. Patches welcome! This repository seems pretty messed up; I'm not even sure what you want from me. Since PPC is now supported in upstream QEMU, does it really matter if it works in qemu-kvm.git? Yes. There are people (me) who still rely on building everything from the same source. It can only be done by the superset (qemu-kvm.git) -- Glauber Costa. Free as in Freedom http://glommer.net The less confident you are, the more serious you have to act. -- 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: qemu-kvm.git now live
Glauber Costa wrote: Yes. There are people (me) who still rely on building everything from the same source. It can only be done by the superset (qemu-kvm.git) Fedora doesn't package a KVM enabled qemu-system-ppcemb, do they? Regards, Anthony Liguori -- 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: qemu-kvm.git now live
On Tue, 2009-04-28 at 17:20 -0500, Anthony Liguori wrote: Hollis Blanchard wrote: On Thu, 2009-04-23 at 18:40 +0300, Avi Kivity wrote: Still missing: - I have not tested powerpc or ia64. Patches welcome! This repository seems pretty messed up; I'm not even sure what you want from me. Since PPC is now supported in upstream QEMU, does it really matter if it works in qemu-kvm.git? I was going to take that position too, except Avi asked me specifically if some of the code inside TARGET_I386 ifdefs in qemu-kvm.c works for other architectures. Since it's a safe bet that some version of this code will probably be submitted to qemu-devel, I figured I'd try a build test... and discovered that qemu-kvm.git was released a little prematurely. -- Hollis Blanchard IBM Linux Technology Center -- 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: qemu-kvm.git now live
On Tue, 2009-04-28 at 17:28 -0500, Anthony Liguori wrote: Glauber Costa wrote: Yes. There are people (me) who still rely on building everything from the same source. It can only be done by the superset (qemu-kvm.git) Fedora doesn't package a KVM enabled qemu-system-ppcemb, do they? The more people who notice when the PowerPC build breaks, the better. -- Hollis Blanchard IBM Linux Technology Center -- 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 1/3] kvm/e500: Do not keep shadow tlb array
-Original Message- From: Hollis Blanchard [mailto:holl...@us.ibm.com] Sent: Wednesday, April 29, 2009 3:34 AM To: Liu Yu-B13201 Cc: kvm-ppc@vger.kernel.org; rkulk...@force10networks.com Subject: Re: [PATCH 1/3] kvm/e500: Do not keep shadow tlb array On Mon, 2009-04-27 at 14:58 +0800, Liu Yu wrote: Shadow tlb array costs a lot memory and incurs potential coherence problem. Remove it and we now translate to shadow mappings directly from guest TLB entries. Signed-off-by: Liu Yu yu@freescale.com Well, funny story... pretty much as soon as we removed the shadow TLB on 440, we put it back. But we use it differently now. Our experience on 440 was that it was a performance win to *also* keep a shadow TLB array, but use that *only* in the vcpu_put/vcpu_load() path instead of tlbia(). In other words, instead of just clearing all that guest TLB state you worked so hard to build up, preserve it across host context switches. We don't use that array for anything other than host context switches. For normal exits (handled in kernel or handled in qemu) we take a less precise shadowy approach, where host and guest TLB entries can compete without KVM's knowledge, and we indiscriminately invalidate them. (Yes, http://www.linux-kvm.org/page/PowerPC_Book_E_MMU is no longer completely accurate.) I'm not sure what the coherence problems are that you allude to, but we never did SMP host support for 440. It's not a SMP coherence problem. But that after we apply shadow id trick, the shadow tlb entry may be expired due to the change of id mapping. As we always update PID0, PID1 to the latest shadow id, write expired shadow entry back is useless and may incur other problem. Moreover after applying shadow id trick, there is no tlbia() in the vcpu_load()/vcpu_put(). So I think it doesn't affect the performance of e500. -- 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
