From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51750) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R36x3-000309-HG for qemu-devel@nongnu.org; Mon, 12 Sep 2011 09:53:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R36x1-000223-Tw for qemu-devel@nongnu.org; Mon, 12 Sep 2011 09:53:33 -0400 Message-ID: <4E6E0ED6.9060507@redhat.com> Date: Mon, 12 Sep 2011 16:53:26 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1315500885-32577-1-git-send-email-agraf@suse.de> <4E6C9068.50508@redhat.com> <4E6DCBDC.8040002@redhat.com> <4E6E0D41.9010902@redhat.com> In-Reply-To: <4E6E0D41.9010902@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] PPC: Fix via-cuda memory registration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Lucas Meneghel Rodrigues , Anthony Liguori Cc: "qemu-ppc@nongnu.org" , Alexander Graf , qemu-devel Developers On 09/12/2011 04:46 PM, Lucas Meneghel Rodrigues wrote: > On 09/12/2011 06:07 AM, Avi Kivity wrote: >> On 09/11/2011 02:38 PM, Alexander Graf wrote: >>> Am 11.09.2011 um 12:41 schrieb Avi Kivity: >>> >>> > On 09/08/2011 07:54 PM, Alexander Graf wrote: >>> >> PS: Please test your patches. This one could have been found with >>> an invocation >>> >> as simple as "qemu-system-ppc". We boot into the OpenBIOS prompt by >>> default, >>> >> so you wouldn't even have required a guest image or kernel. >>> >> >>> > >>> > >>> > Sorry about that. >>> > >>> > Note that it's pretty hard to test these patches. I often don't even >>> know which binary as the device->target relationship is not >>> immediately visible, >>> >>> The patch was explicitly to convert ppc ;). >> >> Yes, in this case. Not in the general case. >> >>> > and I don't really know what to expect from the guest. >>> >>> The very easy check-fundamentals thing to do for ppc is to execute >>> qemu-system-ppc without arguments. It should drop you into an OF >>> prompt. Both memory api bugs on ppc I've seen now would have been >>> exposed with that. >>> >>> I agree that we should have something slightly more sophisticated, but >>> doing such a bare minimum test is almost for free to the tester and >>> covers at least basic functionality :). I don't mind people >>> introducibg subtle bugs in corner cases - these things happen. But an >>> abort() when you execute the binary? That really shouldn't happen >>> ever. This one is almost as bad. >> >> Yeah. >> >>> > It would be best if we had a kvm-autotest testset for tcg, it would >>> probably run in just a few minutes and increase confidence in these >>> patches. >>> >>> Yeah, I am using kvm-autotest today for regression testing, but it's >>> very hard to tell it to run multiple different binaries. The target >>> program variable can only be set for an execution job, making it >>> impossible to run multiple targets in one autotest run. > > Alexander, I've started to work on this, I'm clearing out my request > list, last week I've implemented ticket 50, that was related to > special block configuration for the tests, now I want to make it > possible to support multiple binaries. > >> Probably best to tell autotest about the directory, and let it pick up >> the binary. Still need some configuration to choose between qemu-kvm and >> qemu-system-x86_64. >> >> Lucas? > > Yes, that would also work, having different variants with different > qemu and qemu-img paths. Those binaries would have to be already > pre-built, but then we miss the ability autotest has of building the > binaries and prepare the environment. It'd be like: > > variant1: > qemu = /path/to/qemu1 > qemu-img = /path/to/qemu-img1 > extra_params = "--appropriate --extra --params2" > > > variant2: > qemu = /path/to/qemu2 > qemu-img = /path/to/qemu-img2 > extra_params = "--appropriate --extra --params2" > > Something like that. It's a feasible intermediate solution until I > finish work on supporting multiple userspaces. > Another option is, now that the binary name 'qemu' is available for general use, make it possible to invoke everything with just one binary: qemu -system -target mips ... qemu-system -target mips ... qemu-system-mips ... are all equivalent. autotest should easily be able to pass different -target based on the test being run. -- error compiling committee.c: too many arguments to function