qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH] powerpc: add PVR mask support


From: Alexander Graf
Subject: Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH] powerpc: add PVR mask support
Date: Thu, 15 Aug 2013 08:00:28 +0200

On 15.08.2013, at 07:21, Alexander Graf wrote:

> 
> 
> Am 15.08.2013 um 05:35 schrieb Alexey Kardashevskiy <address@hidden>:
> 
>> IBM POWERPC processors encode PVR as a CPU family in higher 16 bits and
>> a CPU version in lower 16 bits. Since there is no significant change
>> in behavior between versions, there is no point to add every single CPU
>> version in QEMU's CPU list. Also, new CPU versions of already supported
>> CPU won't break the existing code.
>> 
>> This adds a PVR mask support. POWER7, POWER7+ and POWER8 CPUs
>> definitions converted to use masks.
> 
> How does the user select that he wants a v2.3 p7 cpu with this patch?

I figured I should be a bit more verbose here ;).

Today, we have a class hierarchy that looks like this:

  PowerPC
    |- POWER7 v2.2
    `- POWER7 v2.3

with both POWER7 CPUs referencing to the same class_init function.

With your patch, you're changing this to

  PowerPC
    `- POWER7

so we lose all information about major/minor versions.

Now what I think you want is something like

  PowerPC
    `- POWER7
        |- POWER7 v2.2
        `- POWER7 v2.3

Here the POWER7 class can expose PVR mask values which -cpu host can use to 
match against it. -cpu host can then instantiate a "generic" POWER7 object with 
the host's PVR value if it matches. But we still keep the versioned CPU classes 
around for the user to chose from.

This goes even further. We could implement something like -cpu 
POWER7,major=2,minor=3 which should also give us a POWER7 v2.3 CPU and 
essentially be the same as the POWER7 v2.3 class. Instantiating -cpu POWER7 
without parameters should probably default to the latest revision that we're 
aware of.

We can't just remove the POWER7_v23 type because users may depend on its 
availability. Maybe once we implement the above we can declare the explicitly 
versioned CPU types deprecated and remove them 1-2 years later.


Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]