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

[Alexander Graf]

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

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

Ah, you mean we should indicate "This is the QEMU emulated version of device 
x". I think I slowly see what you're getting at. In this case, the fix really 
is to get QEMU work properly, but I like the idea of exposing to the guest that 
a device is emulated by QEMU, and emulated by version X.


Alex