From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53185) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ51u-0001Ct-Ny for qemu-devel@nongnu.org; Tue, 21 Jun 2011 13:46:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QZ51s-0007Xd-RA for qemu-devel@nongnu.org; Tue, 21 Jun 2011 13:46:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1030) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ51s-0007Tb-4V for qemu-devel@nongnu.org; Tue, 21 Jun 2011 13:46:24 -0400 From: Lucas Meneghel Rodrigues Date: Tue, 21 Jun 2011 13:58:19 -0300 In-Reply-To: <4E00A322.2030006@redhat.com> References: <4E008060.5020900@redhat.com> <4E00A1B3.9030508@codemonkey.ws> <4E00A322.2030006@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Message-ID: <1308675502.2566.6.camel@freedom> Mime-Version: 1.0 Subject: Re: [Qemu-devel] KVM call agenda for June 21 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: KVM devel mailing list , quintela@redhat.com, "Justin M. Forbes" , qemu-devel@nongnu.org On Tue, 2011-06-21 at 16:56 +0300, Avi Kivity wrote: > On 06/21/2011 04:50 PM, Anthony Liguori wrote: > > On 06/21/2011 06:28 AM, Avi Kivity wrote: > >> On 06/20/2011 10:42 AM, Juan Quintela wrote: > >>> Please send in any agenda items you are interested in covering. > >>> > >> > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=689672 - Guests do not start > >> after upgrading qemu to 0.13 > >> > >> Seems like our backward compatibility plan isn't working. How do we > >> address it? How do we test it? > > > > f13 is ancient, no? > > Yes, a year old. > > Furthermore, Justin tells me it carries a lot downstream patches. > > > > > I'm not sure what this particular issue is, but is this doing -M pc-0.12? > > > > It has its own machine type. So this report may not indicate any > problem with upstream. > > Still, I feel we have a potential problem here. We identify > guest-visible attributes just by review; we're sure to miss something > here and there. Unlike ordinary bugs, compatibility problems only show > up later and are much harder to fix. > > Second, we don't do any tests in this area that I'm aware of. Lucas, > what would it take (thanks, you're most kind) to test multiple qemus in > a single run? I have thought about it, people have asked about this in the past. Here's my implementation idea: 1) Turn qemu to be a configurable option very much like images, cdroms, nics, etc, such as: qemu_binary_upstream = '/path/1' qemu_binary_rhel6 = '/path/2' ... qemu_binary_n = '/path/n' So people in need of testing multiple qemus can set them and have them all track down by autotest 2) Add support in the build test for building multiple user spaces 3) Make qemu_binary to be a VM param. This way if we need to change the userspace a given VM uses, just update the params and start the vm again. Noticing different params, the VM will be restarted using the alternate userspace. I will start to work on this right now. It'll probably take a couple of weeks for a first patchset, but it's high time we get this implemented, since there are several uses for it. > We can have a script that runs lspci -vvvvvvvvvvvvvvvvvvv, x86info, and > other interesting stuff and compare the results, and also system tests > that boot a guest on multiple qemus (with the same -M and different -M) > and see if things work. > > We can probably continue on email, I don't see a real need for a call > for this topic. >