On 4/5/19 11:02 AM, Daniel P. Berrangé wrote: > On Fri, Apr 05, 2019 at 10:47:54AM +0200, Philippe Mathieu-Daudé wrote: >> Hi Helge, >> >> On 4/5/19 9:56 AM, Helge Deller wrote: >>> On 05.04.19 03:34, Peter Maydell wrote: >>>> On Fri, 5 Apr 2019 at 01:59, Helge Deller <del...@gmx.de> wrote: >>>>> If a non-release architecture is found, and it's known that there is no >>>>> native TCG support for that CPU, automatically fall back to the TCI >>>>> implementation instead of requesting the user to run configure again >>>>> with the --enable-tcg-interpreter option. >>>>> >>>>> This change simplifies building qemu in automatic build environments >>>>> (like in my case the debian buildds) because one does not need to >>>>> special case on the architectures. >>>> >>>> I don't think we should do this. TCI is unmaintained, has several >>>> known flaws, >>> >>> Just out of interest: Is there a list with those flaws somewhere? >> >> The last big discussion is in this thread: >> https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg06528.html
I just noticed this link doesn't show the full thread replies list, and want to point out Stefan's one: https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg06841.html I guess remember someone (Thomas? you Daniel?) posting a link of 3 forks using TCI for reverse engineering but I can't find it to check if they are still active. > Do the various crashes that you illustrate in that cover letter > still exist today ? If so, 2 years of continued brokenness with no > fixes would reinforce the the view that it is time to remove TCI > from the codebase. Or find a maintainer and add tests...
