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
