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

[Alexander Graf]

On 09.08.2012, at 23:28, Scott Wood wrote:

> 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...

I'm not sure I like the idea. Usually, in the real hardware world, erratas 
happen on the board level, right? So we could have a compatible "qemu,1.2-e500" 
in the board compatible. But having one for every device sounds a bit too much 
to me.

Also, not implementing large vectors essentially mean we don't emulate an 
fsl,mpic well. That's fine, let's just not tell the guest we do. I don't think 
we should teach Linux about broken emulation. I'd rather see the emulation 
fixed.

> 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).

Hmm. Yes. Maybe it'd be good to just never check SVR but instead always rely on 
dt properties?


Alex