From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50049) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VE9pR-00007l-1Y for qemu-devel@nongnu.org; Mon, 26 Aug 2013 23:20:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VE9pI-0005rt-4l for qemu-devel@nongnu.org; Mon, 26 Aug 2013 23:20:24 -0400 Received: from e28smtp08.in.ibm.com ([122.248.162.8]:60686) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VE9pH-0005rj-GF for qemu-devel@nongnu.org; Mon, 26 Aug 2013 23:20:16 -0400 Received: from /spool/local by e28smtp08.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 27 Aug 2013 08:38:53 +0530 Received: from d28relay02.in.ibm.com (d28relay02.in.ibm.com [9.184.220.59]) by d28dlp03.in.ibm.com (Postfix) with ESMTP id 7DFEF1258043 for ; Tue, 27 Aug 2013 08:49:58 +0530 (IST) Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64]) by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r7R3LmOf41943164 for ; Tue, 27 Aug 2013 08:51:48 +0530 Received: from d28av02.in.ibm.com (localhost [127.0.0.1]) by d28av02.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r7R3K6qR000478 for ; Tue, 27 Aug 2013 08:50:06 +0530 Message-ID: <521C1A9C.8070901@linux.vnet.ibm.com> Date: Tue, 27 Aug 2013 11:18:52 +0800 From: Lei Li MIME-Version: 1.0 References: <5217BC5F.4060306@twiddle.net> <5217C94F.6010607@weilnetz.de> In-Reply-To: <5217C94F.6010607@weilnetz.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] TCG unit testing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil , Richard Henderson Cc: qemu-devel , Aurelien Jarno On 08/24/2013 04:42 AM, Stefan Weil wrote: > Am 23.08.2013 21:47, schrieb Richard Henderson: >> I've been thinking for a while about how to reliably test TCG backends, and >> maybe how to do regression testing on them. Having to begin the test from a >> guest binary, especially considering the vast cross-compilation problem, is >> pretty much a non-starter. >> >> I've been thinking of a truly stripped down target for the purpose, with a >> special-purpose machine loop and main to go with it. I.e. avoid vl.c. >> >> My current idea is that the test file consists of 3 sections: guest memory >> layout, raw TBs, and expected results. Perhaps best explained with some examples: >> >> (1a) I've split up this test into two TBs to prevent some constant folding. >> (1b) The guest machine should have enough registers to make it easy to perform >> lots of tests at once. Even better if we can avoid the complication of memory. >> > [...] >> Thoughts? Anything that we ought to be testing that I haven't thought of here, >> and that this sort of structure couldn't support? >> >> It may be some time before I can progress this enough to usefulness, but I >> wanted to get this written down while it is fresh in my head. >> >> >> r~ > Since the addition of the TCG interpreter backend, there exist two > backends for each supported host. It is possible to run user code > with well defined instruction order (no asynchronous events like > interrupts) with both backends and to compare the execution > flow. I did that while developing TCI. The process can be reversed: > TCI could be used as reference to test any other backend. > > Another approach for testing TCG backends might work like this: > > Modifying QEMU so that it is possible to feed the TCG backend > with single TCG opcodes would allow testing some part of the > processing chain: > > target opcodes -> tcg opcodes -> host opcodes > <-------------------------> Really nice if we could support this! > > Regards, > Stefan > > -- Lei