Re: [Qemu-devel] [RFC PATCH] spapr: add initial ibm, client-architecture-support rtas call support

[Paul Mackerras]

On Wed, Sep 04, 2013 at 04:32:20PM -0500, Anthony Liguori wrote:
> On Wed, Sep 4, 2013 at 8:37 AM, Alexander Graf <address@hidden> wrote:
> >
> >>
> >>> So IMHO this whole thing should be orthogonal to -cpu.
> >>
> >> Well, since we cannot change CPU class on the fly, yes, it should be a
> >> "compatibility" flags/properties/methods/whatever of the default CPU for
> >> the specific family.
> >
> > Since it's machine global, it could just as well be a machine option, no? 
> > Or can you have multiple CPUs with different compat modes in a single 
> > system?
> 
> AFAIK, this has nothing to do with CPUs.

I'm not sure what you mean by that; it has to do with CPUs since it
means changing the CPUs' behaviour, at least for user-mode programs.

> >>> Why? Just because you're on POWER7 as default doesn't mean you can't bump 
> >>> to a newer compat later on, no?
> >>
> >> Bump when exactly? And it won't be a new compat, it will be a native CPU. I
> >
> > If you configure your guest to boot in POWER7-compat mode on your POWER8 
> > box and it then tells you through ibm,client-architecture-support that it 
> > can do POWER8, we can just remove all the compat bits and be happy, no?

Answering Alex here -- if we want to preserve the option of migrating
to a POWER7 host in future, we would run the guest in POWER7 compat
mode even if the current host is a POWER8 and the guest knows about
POWER8.

> POWER8 is compatible with POWER7, right?  There's no magic bits that
> need to be disabled AFAIK.

POWER8 is a superset of POWER7, yes, but what we want to do when
running an old OS and applications that don't know about POWER8 is to
disable the new POWER8 features in usermode (e.g., transactional
memory, various other new instructions, etc.).  The reason is to make
it more likely that applications won't misbehave even if they do
silly things like trying instructions that aren't defined on POWER7
(or at least, they will behave the same as they would on a real
POWER7).

To this end, the processor has a Processor Compatibility Register
(PCR) which has bits which disables the new instructions and SPRs when
the processor is in user mode - actually 2 bits, one which disables
the features that were new for POWER8 compared to POWER7, and one
which disables the features that were new for POWER7 compared to
POWER6.

> The effective version if exposed through device tree.  The reason a
> reboot is needed is because the device tree needs to be updated (which
> can't be done without a reboot).
> 
> The problem to solve is delaying device tree generation in order to
> avoid the reboots, no?

No, we can't delay generating the device tree to that point.  SLOF
needs the device tree, and the kernel does look at the device tree
before calling the ibm,client-architecture-support method.

> (Maybe it's time to start thinking of non-PAPR interfaces that Linux
> KVM guests can use to avoid a lot of this silliness...)

That won't help us boot (e.g.) RHEL6 or SLES11 on a POWER8, which is
what this is ultimately about.

In any case, there are changes we might need to make that will
definitely need a reboot - changing the size of the hashed page table,
for instance.

Paul.