From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51674) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgJUt-000092-H2 for qemu-devel@nongnu.org; Thu, 29 Dec 2011 12:10:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RgJUl-0000ME-8F for qemu-devel@nongnu.org; Thu, 29 Dec 2011 12:10:31 -0500 Received: from mail-yx0-f173.google.com ([209.85.213.173]:51226) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgJUl-0000M8-2z for qemu-devel@nongnu.org; Thu, 29 Dec 2011 12:10:23 -0500 Received: by yenm6 with SMTP id m6so8964606yen.4 for ; Thu, 29 Dec 2011 09:10:22 -0800 (PST) Message-ID: <4EFC9EF8.7040600@codemonkey.ws> Date: Thu, 29 Dec 2011 11:10:16 -0600 From: Anthony Liguori 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> In-Reply-To: <4EFC9D7B.2010408@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Avi Kivity Cc: "lmr@redhat.com" , Stefan Hajnoczi , cleber@redhat.com, dlaor@redhat.com, qemu-devel , Gerd Hoffmann , Cleber Rosa 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. Maybe over time, we'll have a good enough libOS for qtest that qemu-test won't be that useful anymore. But in the short term, I think we'll get more test coverage by having both. >>> >>> You mention in the changelog replacing the APIC. Why can't you do that? >> >> >> I currently replace the I/O APIC which seems to be limited to 16 >> 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. Ah, okay, I wasn't thinking of that. I'll clean qtest up and resubmit next week. >>> It looks great. One thing I'd change is to use the qmp protocol >>> (perhaps not the monitor, just the schema/codegen). Does something >>> prohibit this? >> >> >> Yeah, I thought about using QMP. But events are posted in QMP which >> means that you never get an explicit ACK. That may not be a problem >> but it's something I had in mind. >> >> 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. Regards, Anthony Liguori