From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40655) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R32UT-0002VH-Ks for qemu-devel@nongnu.org; Mon, 12 Sep 2011 05:07:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R32US-00048j-JJ for qemu-devel@nongnu.org; Mon, 12 Sep 2011 05:07:45 -0400 Message-ID: <4E6DCBDC.8040002@redhat.com> Date: Mon, 12 Sep 2011 12:07:40 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1315500885-32577-1-git-send-email-agraf@suse.de> <4E6C9068.50508@redhat.com> In-Reply-To: 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: Alexander Graf Cc: Lucas Meneghel Rodrigues , "qemu-ppc@nongnu.org" , qemu-devel Developers 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. 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? > > Also, not all targets implement enough functionality for autotest. The e500 machine for example doesn't support power off - real hw doesn't either. So we always have to kill the vm exposing potential data loss. 'quit' from the monitor should cause any data loss. You can get the guest to sync by telling it via ssh (or just ignore the guest - who cares?) > But that's probably gone by now with cache=unsafe fixed with your previous patches :). However that means that a simple test run takes quite a while already thanks to timeouts. > Why should you have any timeouts? Sample the screen until you reach the desired state, or perhaps ssh into the guest and test things, then (qemu) quit. -- error compiling committee.c: too many arguments to function