Re: [Qemu-devel] [Qemu-ppc] [PATCH 56/72] PPC: e500: Use new MPIC dt format

[Scott Wood]

On 08/09/2012 04:19 PM, Alexander Graf wrote:
> 
> On 09.08.2012, at 23:11, Scott Wood wrote:
> 
>> On 08/09/2012 04:01 PM, Alexander Graf wrote:
>>>
>>> On 09.08.2012, at 22:58, Scott Wood wrote:
>>>> Additionally, we should consider adding extra compatibles with the major
>>>> QEMU version in them, so that QEMU-aware target code can work around
>>>> QEMU limitations even if it's been fixed in a more recent QEMU.
>>>>
>>>> I think this is what you were getting at in the e500 platform
>>>> discussion, when you pointed at the PC versioning, but it's not about
>>>> documenting semantics so much as identifying the actual implementation.
>>>
>>> Yes, -M e500-1.2 should expose chrp,open-pic while -M e500 should expose 
>>> fsl,mpic.
>>
>> We could do that too if the chrp,open-pic version actually makes it into
>> a release before we fix fsl,mpic (I don't know what the release schedule
> 
> We are past soft freeze, hard feature freeze is coming up next week.
> 
>> is), but what I meant was that the device tree should have something like
>> compatible = "qemu,1.2-chrp-openpic", "chrp,open-pic"
>> or
>> compatible = "qemu,1.3-fsl-mpic", "fsl,mpic"
>>
>> ...so that we can run new kernels on old QEMUs, not just the other way
>> around.
> 
> Why would we bother?

Why not?  It's much easier than the other way around -- it's just an
extra string in the device tree.  It's up to someone who cares to put
relevant workarounds in the kernel.

Compare it to real hardware, where we expect new kernels to run on old
hardware but not the other way around, and where we expect to be able to
identify the specific hardware we're running on (there are version
registers in the MPIC for identifying real hardware version, but not
QEMU implementation version).

If we had this, we could have avoided needing to postpone fsl,mpic,
because I think the Linux patch using large vectors hasn't been released
yet, so we could have added a check for qemu,1.2-fsl-mpic and known that
it didn't include large vectors.  I guess it's still not too late...

It would also be useful for overriding SVR checks in drivers (for errata
and such), which can get particularly awkward if you mix some emulated
devices with some directly assigned devices (no one SVR will be right
for all of them, even if all the emulated devices faithfully emulate one
SoC's behavior).

-Scott