>> Apart from the points you have raised about specific patches there >> were few more minor bugs in the series spotted by Juha Riihimäki >> <juha.riihim...@nokia.com>. A fix is available at >> http://repo.or.cz/w/qemu/navara.git?a=commit;h=2ce696baa6fc5d99522cf387b6a4913807fd43ed > > One of the fix was already in my branch (catched by Laurent > Desnogues). > I have added the other fixes in my branch. The last to hunks are good > example why temp new/free should be done explicitly ;)
I think I have a couple of other fixes and patches on top of that as well, but I'd rather wait until you get this bunch committed and then format the patches against the new mainline so that they apply. On the subject of the new_tmp/dead_tmp, can you elaborate how critical it is if there are resource leaks in the translator code, i.e. if some of the temporary variables don't get marked dead? I suppose the leakage would only affect the translation of the code block where it appears? I found more leaks by introducing a new_tmp64/dead_tmp64 and some other checkups to catch programming errors. Some of the generated tcg code is not very optimal, for example a single vld4.8 instruction can generate over 250 tcg ops. I did some optimizations and got it under 200 but do you think it could be an issue that a single instruction can expand to so many tcg ops? I mean besides the fact that it causes TBs for only one or two guest instructions to be generated. Perhaps this would also be a good place and time to also ask whether you would be interested in integrating support for OMAP3 in the QEMU mainline? We have been developing and using it for several months now, it's based on the work done by Yajin <ya...@vm-kernel.org> to support the OMAP3 BeagleBoard hardware. We have added support for the Nokia N900 system emulation as well. In my personal opinion the OMAP3 emulation is in functionality on par with the existing OMAP2 emulation, if not even more complete. Cheers, Juha
