From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45798) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgJd4-0000rY-La for qemu-devel@nongnu.org; Thu, 29 Dec 2011 12:18:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RgJd3-0001md-7i for qemu-devel@nongnu.org; Thu, 29 Dec 2011 12:18:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:1029) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgJd2-0001mW-S4 for qemu-devel@nongnu.org; Thu, 29 Dec 2011 12:18:57 -0500 Message-ID: <4EFCA0F9.2090101@redhat.com> Date: Thu, 29 Dec 2011 19:18:49 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4EEF70B4.3070109@us.ibm.com> <4EF73EF5.8050606@redhat.com> <4EF88EC0.8020301@codemonkey.ws> <4EF8FC88.70809@redhat.com> <4EFA4829.4000207@redhat.com> <4EFA80EA.3050405@codemonkey.ws> <4EFAA2A2.4000107@redhat.com> <4EFB2764.7040006@codemonkey.ws> <4EFB2F36.2090408@redhat.com> <4EFB35AB.6040003@redhat.com> <4EFB4757.4020504@codemonkey.ws> <4EFB5138.5020502@redhat.com> <4EFC916E.4070902@codemonkey.ws> <4EFC9706.4090500@redhat.com> <4EFC9A04.3030004@codemonkey.ws> <4EFC9D7B.2010408@redhat.com> <4EFC9EF8.7040600@codemonkey.ws> In-Reply-To: <4EFC9EF8.7040600@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "lmr@redhat.com" , Stefan Hajnoczi , cleber@redhat.com, dlaor@redhat.com, qemu-devel , Gerd Hoffmann , Cleber Rosa On 12/29/2011 07:10 PM, Anthony Liguori wrote: > On 12/29/2011 11:03 AM, Avi Kivity wrote: >> On 12/29/2011 06:49 PM, Anthony Liguori wrote: >>>> However, I don't think it's even necessary. From a quick read of the >>>> manual, SMBIOS is just a set of static tables in memory which are >>>> picked >>>> up using a signature. So all we need to do is boot an empty guest, >>>> read >>>> its memory, and look for the tables. >>> >>> Doesn't it sound a whole nicer use linux.git to parse this information >>> for us in a friendly, easy to consume fashion? >> >> Run 'dmidecode -d /path/to/memory/dump', if you must. >> >> I don't think the qemu-test approach is bad, per se, it's just that >> qtest is better. It gives you full control over what to fingerprint and >> is not reliant on Linux not changing. > > Maybe. But I feel a lot more comfortable asking people to write > qemu-test's than writing low level logic to do this stuff in qtest. Writing the libOS is definitely a job for the (sub-)maintainers. The work to code a unit test for patch X should be O(X). >>> IRQs. I think MSI takes a side channel directly to the local APIC, no? >> >> Yes, writes to the 1MB @ 0xfee00000 gets translated to MSIs. So you >> just translate them to events. > I currently replace the I/O APIC which seems to be limited to 16 > > Ah, okay, I wasn't thinking of that. I'll clean qtest up and resubmit > next week. Great. I'll be happy to help writing libOS. >>> It also seemed to be reasonably complicated without a clear >>> advantage. qtest isn't going to be a supported protocol so we can >>> certainly change it down the road if we want to. >> >> It's a pity not to reuse all the tooling? Seems like self-NIH. > > > No, it's just going to be more work to reuse things. I was careful > to make sure that it was possible down the road. > > We have a bit of way to go before the QAPI infrastructure is generic > enough to be used for something like this. I've started to simplify the build procedure, maybe it will help a tiny bit. -- error compiling committee.c: too many arguments to function