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
