Commit Message

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 <scottwood@freescale.com>
---
arch/powerpc/kernel/entry_32.S | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)

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

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

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.

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.