[PATCH][v3] KVM: PPC: add paravirt idle loop for 64-bit book E
From: Stuart Yoder Signed-off-by: Stuart Yoder --- -v3 -whitespace cleanup, deleted stray comma, added comment arch/powerpc/kernel/epapr_hcalls.S |2 ++ arch/powerpc/kernel/idle_book3e.S | 32 ++-- 2 files changed, 32 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/epapr_hcalls.S b/arch/powerpc/kernel/epapr_hcalls.S index 62c0dc2..9f1ebf7 100644 --- a/arch/powerpc/kernel/epapr_hcalls.S +++ b/arch/powerpc/kernel/epapr_hcalls.S @@ -17,6 +17,7 @@ #include #include +#ifndef CONFIG_PPC64 /* epapr_ev_idle() was derived from e500_idle() */ _GLOBAL(epapr_ev_idle) CURRENT_THREAD_INFO(r3, r1) @@ -42,6 +43,7 @@ epapr_ev_idle_start: * _TLF_NAPPING. */ b idle_loop +#endif /* Hypercall entry point. Will be patched with device tree instructions. */ .global epapr_hypercall_start diff --git a/arch/powerpc/kernel/idle_book3e.S b/arch/powerpc/kernel/idle_book3e.S index 4c7cb400..bfb73cc 100644 --- a/arch/powerpc/kernel/idle_book3e.S +++ b/arch/powerpc/kernel/idle_book3e.S @@ -16,11 +16,13 @@ #include #include #include +#include /* 64-bit version only for now */ #ifdef CONFIG_PPC64 -_GLOBAL(book3e_idle) +.macro BOOK3E_IDLE name loop +_GLOBAL(\name) /* Save LR for later */ mflrr0 std r0,16(r1) @@ -67,7 +69,33 @@ _GLOBAL(book3e_idle) /* We can now re-enable hard interrupts and go to sleep */ wrteei 1 -1: PPC_WAIT(0) + \loop + +.endm + +.macro BOOK3E_IDLE_LOOP +1: + PPC_WAIT(0) b 1b +.endm + +/* epapr_ev_idle_start below is patched with the proper hcall + opcodes during kernel initialization */ +.macro EPAPR_EV_IDLE_LOOP +idle_loop: + LOAD_REG_IMMEDIATE(r11, EV_HCALL_TOKEN(EV_IDLE)) + +.global epapr_ev_idle_start +epapr_ev_idle_start: + li r3, -1 + nop + nop + nop + b idle_loop +.endm + +BOOK3E_IDLE epapr_ev_idle EPAPR_EV_IDLE_LOOP + +BOOK3E_IDLE book3e_idle BOOK3E_IDLE_LOOP #endif /* CONFIG_PPC64 */ -- 1.7.9.7 -- 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: [PULL 3.8 0/1] ppc patch queue 2013-01-18 for 3.8
On Thu, Jan 24, 2013 at 07:23:10PM +0100, Alexander Graf wrote: > > On 22.01.2013, at 00:36, Marcelo Tosatti wrote: > > > On Fri, Jan 18, 2013 at 12:48:25AM +0100, Alexander Graf wrote: > >> Hi Marcelo / Gleb, > >> > >> This is my current patch queue for ppc against 3.8. Please pull. > >> > >> It contains a bug fix for an issue that Ben Collins ran into, where > >> a guest would just abort because it traps during an unknown instruction. > >> > >> Alex > >> > >> > >> The following changes since commit > >> dfdebc24837ed0a1d6ad73b108a10d3c88d1b6e8: > >> Linus Torvalds (1): > >>Merge tag 'for-linus-v3.8-rc4' of git://oss.sgi.com/xfs/xfs > >> > >> are available in the git repository at: > >> > >> git://github.com/agraf/linux-2.6.git kvm-ppc-3.8 > >> > >> Alexander Graf (1): > >> KVM: PPC: Emulate dcbf > >> > >> arch/powerpc/kvm/emulate.c |2 ++ > >> 1 files changed, 2 insertions(+), 0 deletions(-) > > > > Pulled, thanks. > > Into which queue? kvm.git doesn't contain it anywhere. > master. -- Gleb. -- 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][v2] KVM: PPC: add paravirt idle loop for 64-bit book E
> -Original Message- > From: Wood Scott-B07421 > Sent: Thursday, January 24, 2013 12:22 PM > To: Yoder Stuart-B08248 > Cc: ag...@suse.de; b...@kernel.crashing.org; linuxppc-...@ozlabs.org; > kvm-ppc@vger.kernel.org; > k...@vger.kernel.org; Yoder Stuart-B08248 > Subject: Re: [PATCH][v2] KVM: PPC: add paravirt idle loop for 64-bit book E > > On 01/22/2013 05:54:43 PM, Stuart Yoder wrote: > > +.macro BOOK3E_IDLE_LOOP > > +1: > > + PPC_WAIT(0) > > b 1b > > +.endm > > + > > +.macro EPAPR_EV_IDLE_LOOP > > +idle_loop: > > + LOAD_REG_IMMEDIATE(r11, EV_HCALL_TOKEN(EV_IDLE)) > > + > > +.global epapr_ev_idle_start > > +epapr_ev_idle_start: > > + li r3, -1 > > + nop > > + nop > > + nop > > + b idle_loop > > +.endm > > + > > +BOOK3E_IDLE epapr_ev_idle, EPAPR_EV_IDLE_LOOP > > + > > +BOOK3E_IDLE book3e_idle BOOK3E_IDLE_LOOP > > Why the comma after epapr_ev_idle but not after book3e_idle? > > Also you have spaces where there should be tabs. > > Otherwise looks good. Hmm...there shouldn't be a comma there. I'll respin and fix the whitespace too. Stuart -- 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: [PULL 3.8 0/1] ppc patch queue 2013-01-18 for 3.8
On 22.01.2013, at 00:36, Marcelo Tosatti wrote: > On Fri, Jan 18, 2013 at 12:48:25AM +0100, Alexander Graf wrote: >> Hi Marcelo / Gleb, >> >> This is my current patch queue for ppc against 3.8. Please pull. >> >> It contains a bug fix for an issue that Ben Collins ran into, where >> a guest would just abort because it traps during an unknown instruction. >> >> Alex >> >> >> The following changes since commit dfdebc24837ed0a1d6ad73b108a10d3c88d1b6e8: >> Linus Torvalds (1): >>Merge tag 'for-linus-v3.8-rc4' of git://oss.sgi.com/xfs/xfs >> >> are available in the git repository at: >> >> git://github.com/agraf/linux-2.6.git kvm-ppc-3.8 >> >> Alexander Graf (1): >> KVM: PPC: Emulate dcbf >> >> arch/powerpc/kvm/emulate.c |2 ++ >> 1 files changed, 2 insertions(+), 0 deletions(-) > > Pulled, thanks. Into which queue? kvm.git doesn't contain it anywhere. Alex -- 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][v2] KVM: PPC: add paravirt idle loop for 64-bit book E
On 01/22/2013 05:54:43 PM, Stuart Yoder wrote: +.macro BOOK3E_IDLE_LOOP +1: + PPC_WAIT(0) b 1b +.endm + +.macro EPAPR_EV_IDLE_LOOP +idle_loop: + LOAD_REG_IMMEDIATE(r11, EV_HCALL_TOKEN(EV_IDLE)) + +.global epapr_ev_idle_start +epapr_ev_idle_start: + li r3, -1 + nop + nop + nop + b idle_loop +.endm + +BOOK3E_IDLE epapr_ev_idle, EPAPR_EV_IDLE_LOOP + +BOOK3E_IDLE book3e_idle BOOK3E_IDLE_LOOP Why the comma after epapr_ev_idle but not after book3e_idle? Also you have spaces where there should be tabs. Otherwise looks good. -Scott -- 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 v3 0/8] KVM: PPC: e500: Shadow TLB Improvements v3
On 18.01.2013, at 15:38, Alexander Graf wrote: > This patch set improves the shadow TLB handling of our e500 > target. > > The really important bit here is that with these patches applied, > we can map guest TLB1 entries into the host's TLB0. This gives a > significant performance improvement as you can see below. > > Alex Applied to kvm-ppc-queue. Alex -- 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][v2] KVM: PPC: add paravirt idle loop for 64-bit book E
On 23.01.2013, at 00:54, Stuart Yoder wrote: > From: Stuart Yoder > > Signed-off-by: Stuart Yoder Ben, this one is in generic powerpc code, so I'd say it's for you :). Alex > --- > > -v2 > -macro'ized loop in idle_book3e.S to avoid code >duplication, paravirt loop is now in idle_book3e.S > > arch/powerpc/kernel/epapr_hcalls.S |2 ++ > arch/powerpc/kernel/idle_book3e.S | 30 -- > 2 files changed, 30 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/kernel/epapr_hcalls.S > b/arch/powerpc/kernel/epapr_hcalls.S > index 62c0dc2..9f1ebf7 100644 > --- a/arch/powerpc/kernel/epapr_hcalls.S > +++ b/arch/powerpc/kernel/epapr_hcalls.S > @@ -17,6 +17,7 @@ > #include > #include > > +#ifndef CONFIG_PPC64 > /* epapr_ev_idle() was derived from e500_idle() */ > _GLOBAL(epapr_ev_idle) > CURRENT_THREAD_INFO(r3, r1) > @@ -42,6 +43,7 @@ epapr_ev_idle_start: >* _TLF_NAPPING. >*/ > b idle_loop > +#endif > > /* Hypercall entry point. Will be patched with device tree instructions. */ > .global epapr_hypercall_start > diff --git a/arch/powerpc/kernel/idle_book3e.S > b/arch/powerpc/kernel/idle_book3e.S > index 4c7cb400..e1c9acd 100644 > --- a/arch/powerpc/kernel/idle_book3e.S > +++ b/arch/powerpc/kernel/idle_book3e.S > @@ -16,11 +16,13 @@ > #include > #include > #include > +#include > > /* 64-bit version only for now */ > #ifdef CONFIG_PPC64 > > -_GLOBAL(book3e_idle) > +.macro BOOK3E_IDLE name loop > +_GLOBAL(\name) > /* Save LR for later */ > mflrr0 > std r0,16(r1) > @@ -67,7 +69,31 @@ _GLOBAL(book3e_idle) > > /* We can now re-enable hard interrupts and go to sleep */ > wrteei 1 > -1: PPC_WAIT(0) > + \loop > + > +.endm > + > +.macro BOOK3E_IDLE_LOOP > +1: > + PPC_WAIT(0) > b 1b > +.endm > + > +.macro EPAPR_EV_IDLE_LOOP > +idle_loop: > + LOAD_REG_IMMEDIATE(r11, EV_HCALL_TOKEN(EV_IDLE)) > + > +.global epapr_ev_idle_start > +epapr_ev_idle_start: > + li r3, -1 > + nop > + nop > + nop > + b idle_loop > +.endm > + > +BOOK3E_IDLE epapr_ev_idle, EPAPR_EV_IDLE_LOOP > + > +BOOK3E_IDLE book3e_idle BOOK3E_IDLE_LOOP > > #endif /* CONFIG_PPC64 */ > -- > 1.7.9.7 > > -- 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-ppc] [qemu-ppc] quesstion about kvm e500 tlb search method
On 24.01.2013, at 15:36, Wangkai (Kevin,C) wrote: > Hi Alex, > > In reply your mail: > Could you please point me to the respective part of the documentation? > Oh, I am sorry I just see the figure 12-4 of the L2mmu lookup (PowerPC e500 > Core Family Reference Manual .pdf page 12-8) > > And I check it again, it says: > Additionally, Figure 12-4 shows that when the L2 MMU is checked for a TLB > entry, both TLB1 > and TLB0 are checked in parallel. Ah :). Good. > Let me try to understand what you're trying to fix. Are you seeing > performance issues? What kernel are you running on? Are you using hugetlbfs? > There are a lot of things that improve performance a lot more than this > change would. > > Yes, I used a very old version, which is linux 2.6.34, and I find the > performance is not good enough, > which have no support hugetlbfs, And the code of l2mmu lookup is just walk > through all the entry of TLB, and later we will > Try to merge the new fetcher to this version. There have been a number of performance improvements since 2.6.34. Could you please try to run the current upstream code with hugetlbfs on your hardware to get a feeling for what performance numbers are realistic with kvm on e500? With this, you could then either 1) try to backport the current state to 2.6.34 or 2) go to a newer kernel but at least you know what is possible with the technology at hand. Running the state as of 2.6.34 any performance numbers will be devastating. Also, I have a patch set that is not yet applied upstream, which should speed up TLB1 misses a lot. Please check out http://www.mail-archive.com/kvm@vger.kernel.org/msg84609.html That one gives you a significant performance boost when running without hugetlbfs - which would be the case on 2.6.34. So if you were to decide for 1), you could take the current code plus that patch set and hopefully get reasonable performance out of the system. Alex -- 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-ppc] [qemu-ppc] quesstion about kvm e500 tlb search method
Hi Kevin,
On 24.01.2013, at 14:15, Wangkai (Kevin,C) wrote:
> Dear,
>
> I check e500 core reference when the e500 core lookup for L2mmu entries,
> TLB1 is preferred to TLB0.
Could you please point me to the respective part of the documentation?
> And for e500 KVM l2mmu lookup, I find that TLB0 is searched first, and it
> Was done by software.
>
> And I suggest we can search TLB1 first, because TLB0 have more entries
> Than TLB1, and this can improve the guest kernel performance very much.
Actually TLB1 has more entries, because we only search one set at a time. For
TLB1, one set means "all entries" which on e500mc would mean 64. For TLB0, we
only need to check 4 entries. So looking at TLB0 is a lot faster.
Also, most misses in "normal" real world workloads should happen in user space.
> Can I do this change to the kvm code? Is there some other affect?
Let me try to understand what you're trying to fix. Are you seeing performance
issues? What kernel are you running on? Are you using hugetlbfs? There are a
lot of things that improve performance a lot more than this change would.
Also, let me CC kvm-ppc@vger, since you're really asking a KVM question here :).
Alex
>
> Thanks!
> Wangkai
>
>
> int kvmppc_e500_tlb_search(struct kvm_vcpu *vcpu,
> gva_t eaddr, unsigned int pid, int as)
> {
>struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
>int esel, tlbsel;
>
>for (tlbsel = 0; tlbsel < 2; tlbsel++) { // first tlb0, and then tlb1
> esel = kvmppc_e500_tlb_index(vcpu_e500, eaddr, tlbsel, pid, as);
> if (esel >= 0)
> return index_of(tlbsel, esel);
>}
>
>return -1;
> }
>
>
--
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
