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

[Scott Wood]

On 08/09/2012 04:36 PM, Alexander Graf wrote:
> 
> 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:
>>>> ...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?

More often on a chip revision level.

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

But not every device is necessarily emulated.

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

My point is even after we add large vector support, we probably aren't
100% emulating an FSL MPIC.

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

That assumes we know about the problem when the device tree is created
(we like to maintain compatibility with old trees), and that we maintain
the information accurately in all trees (which means u-boot fixups, and
compatibility is even more of an issue there, because some people don't
like upgrading u-boot in the field).  The only practical way to do that
would be to put the SVR in each device tree node, which seems like
overkill.  At least the QEMU compatibles only affect QEMU and target
code that specifically wants to improve its QEMU compatibility, rather
than wait for QEMU to improve.

-Scott