Re: [PATCH] powerpc/booke: Eliminate rfi from exception entry path.

2012-07-10 Thread Benjamin Herrenschmidt
On Tue, 2012-07-10 at 19:47 -0500, Scott Wood wrote:
> On 07/10/2012 07:44 PM, Alexander Graf wrote:
> > 
> > On 11.07.2012, at 02:34, Scott Wood wrote:
> >> +#ifdef CONFIG_BOOKE
> >> +  /*
> >> +   * We're not changing address space on Book E, and the extra rfi
> >> +   * can hurt when virtualized without hardware support -- whereas
> >> +   * mtmsr can be paravirtualized.
> > 
> > We can always paravirtualize RFI as well if it makes sense.
> 
> I'm not sure that's possible.  We thought about it a while back, but
> IIRC the difficulty was not leaving a register clobbered.

Besides mtmsr is slow on real HW as well. Also paravirt as done today
for complex instructions like mtmsr is racy :-) (I already had a chat
about that with Alex a while back, we might want to re-consider what
kind of fix can be done at some point).

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/booke: Eliminate rfi from exception entry path.

2012-07-10 Thread Benjamin Herrenschmidt
On Tue, 2012-07-10 at 19:41 -0500, Scott Wood wrote:
> On 07/10/2012 07:36 PM, Benjamin Herrenschmidt wrote:
> > On Tue, 2012-07-10 at 19:34 -0500, Scott Wood wrote:
> >> Unlike classic, we don't really need the MSR change to be atomic with the
> >> branch.  This eliminates a trap as a KVM guest (in the absence of
> >> hardware hypervisor extensions), where mtmsr is paravirtualized but rfi
> >> is not.  For a virtualized guest without any paravirtualization, this
> >> eliminates an additional two traps (SRR0/1).
> > 
> > In fact, I wonder, what do we write into the MSR at this point that
> > wasn't already in it in BookE ? RI ? I wonder if we could get away
> > without the mtmsr alltogether...
> 
> Doesn't EE get set there for some exceptions?

It does, tho arguably it shouldn't in most cases :-) I'm happy to turn a
bunch of these into explicit local_irq_enable() in the C code though
which will turn into a wrteei which is more efficient on BookE.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/booke: Eliminate rfi from exception entry path.

2012-07-10 Thread Scott Wood
On 07/10/2012 07:44 PM, Alexander Graf wrote:
> 
> On 11.07.2012, at 02:34, Scott Wood wrote:
>> +#ifdef CONFIG_BOOKE
>> +/*
>> + * We're not changing address space on Book E, and the extra rfi
>> + * can hurt when virtualized without hardware support -- whereas
>> + * mtmsr can be paravirtualized.
> 
> We can always paravirtualize RFI as well if it makes sense.

I'm not sure that's possible.  We thought about it a while back, but
IIRC the difficulty was not leaving a register clobbered.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/booke: Eliminate rfi from exception entry path.

2012-07-10 Thread Alexander Graf

On 11.07.2012, at 02:34, Scott Wood wrote:

> Unlike classic, we don't really need the MSR change to be atomic with the
> branch.  This eliminates a trap as a KVM guest (in the absence of
> hardware hypervisor extensions), where mtmsr is paravirtualized but rfi
> is not.  For a virtualized guest without any paravirtualization, this
> eliminates an additional two traps (SRR0/1).
> 
> Signed-off-by: Scott Wood 
> ---
> arch/powerpc/kernel/entry_32.S |   16 
> 1 files changed, 16 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
> index ba3aeb4..6bb637c 100644
> --- a/arch/powerpc/kernel/entry_32.S
> +++ b/arch/powerpc/kernel/entry_32.S
> @@ -193,6 +193,9 @@ transfer_to_handler_cont:
>   lwz r11,0(r9)   /* virtual address of handler */
>   lwz r9,4(r9)/* where to go when done */
> #ifdef CONFIG_TRACE_IRQFLAGS
> +#ifdef CONFIG_BOOKE
> + mtmsr   r10
> +#else
>   lis r12,reenable_mmu@h
>   ori r12,r12,reenable_mmu@l
>   mtspr   SPRN_SRR0,r12
> @@ -201,6 +204,7 @@ transfer_to_handler_cont:
>   RFI
> reenable_mmu: /* re-enable mmu so we can */
>   mfmsr   r10
> +#endif /* !CONFIG_BOOKE */
>   lwz r12,_MSR(r1)
>   xor r10,r10,r12
>   andi.   r10,r10,MSR_EE  /* Did EE change? */
> @@ -247,11 +251,23 @@ reenable_mmu:   /* re-enable 
> mmu so we can */
>   mtlrr9
>   bctr/* jump to handler */
> #else /* CONFIG_TRACE_IRQFLAGS */
> +#ifdef CONFIG_BOOKE
> + /*
> +  * We're not changing address space on Book E, and the extra rfi
> +  * can hurt when virtualized without hardware support -- whereas
> +  * mtmsr can be paravirtualized.

We can always paravirtualize RFI as well if it makes sense.


Alex

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/booke: Eliminate rfi from exception entry path.

2012-07-10 Thread Scott Wood
On 07/10/2012 07:36 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2012-07-10 at 19:34 -0500, Scott Wood wrote:
>> Unlike classic, we don't really need the MSR change to be atomic with the
>> branch.  This eliminates a trap as a KVM guest (in the absence of
>> hardware hypervisor extensions), where mtmsr is paravirtualized but rfi
>> is not.  For a virtualized guest without any paravirtualization, this
>> eliminates an additional two traps (SRR0/1).
> 
> In fact, I wonder, what do we write into the MSR at this point that
> wasn't already in it in BookE ? RI ? I wonder if we could get away
> without the mtmsr alltogether...

Doesn't EE get set there for some exceptions?

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/booke: Eliminate rfi from exception entry path.

2012-07-10 Thread Benjamin Herrenschmidt
On Tue, 2012-07-10 at 19:34 -0500, Scott Wood wrote:
> Unlike classic, we don't really need the MSR change to be atomic with the
> branch.  This eliminates a trap as a KVM guest (in the absence of
> hardware hypervisor extensions), where mtmsr is paravirtualized but rfi
> is not.  For a virtualized guest without any paravirtualization, this
> eliminates an additional two traps (SRR0/1).

In fact, I wonder, what do we write into the MSR at this point that
wasn't already in it in BookE ? RI ? I wonder if we could get away
without the mtmsr alltogether...

Cheers,
Ben.

> Signed-off-by: Scott Wood 
> ---
>  arch/powerpc/kernel/entry_32.S |   16 
>  1 files changed, 16 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
> index ba3aeb4..6bb637c 100644
> --- a/arch/powerpc/kernel/entry_32.S
> +++ b/arch/powerpc/kernel/entry_32.S
> @@ -193,6 +193,9 @@ transfer_to_handler_cont:
>   lwz r11,0(r9)   /* virtual address of handler */
>   lwz r9,4(r9)/* where to go when done */
>  #ifdef CONFIG_TRACE_IRQFLAGS
> +#ifdef CONFIG_BOOKE
> + mtmsr   r10
> +#else
>   lis r12,reenable_mmu@h
>   ori r12,r12,reenable_mmu@l
>   mtspr   SPRN_SRR0,r12
> @@ -201,6 +204,7 @@ transfer_to_handler_cont:
>   RFI
>  reenable_mmu:/* re-enable mmu so we can */
>   mfmsr   r10
> +#endif /* !CONFIG_BOOKE */
>   lwz r12,_MSR(r1)
>   xor r10,r10,r12
>   andi.   r10,r10,MSR_EE  /* Did EE change? */
> @@ -247,11 +251,23 @@ reenable_mmu:   /* re-enable 
> mmu so we can */
>   mtlrr9
>   bctr/* jump to handler */
>  #else /* CONFIG_TRACE_IRQFLAGS */
> +#ifdef CONFIG_BOOKE
> + /*
> +  * We're not changing address space on Book E, and the extra rfi
> +  * can hurt when virtualized without hardware support -- whereas
> +  * mtmsr can be paravirtualized.
> +  */
> + mtmsr   r10
> + mtctr   r11
> + mtlrr9
> + bctr
> +#else
>   mtspr   SPRN_SRR0,r11
>   mtspr   SPRN_SRR1,r10
>   mtlrr9
>   SYNC
>   RFI /* jump to handler, enable MMU */
> +#endif /* !CONFIG_BOOKE */
>  #endif /* CONFIG_TRACE_IRQFLAGS */
>  
>  #if defined (CONFIG_6xx) || defined(CONFIG_E500)


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev