From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43319) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3Dhd-0007DN-4Q for qemu-devel@nongnu.org; Mon, 12 Sep 2011 17:06:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R3Dhb-0006Me-RK for qemu-devel@nongnu.org; Mon, 12 Sep 2011 17:06:05 -0400 Message-ID: <4E6E7437.5010900@codemonkey.ws> Date: Mon, 12 Sep 2011 16:05:59 -0500 From: Anthony Liguori 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> <4E6E0ED6.9060507@redhat.com> In-Reply-To: <4E6E0ED6.9060507@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: Avi Kivity Cc: Lucas Meneghel Rodrigues , "qemu-ppc@nongnu.org" , Alexander Graf , qemu-devel Developers On 09/12/2011 08:53 AM, Avi Kivity wrote: > 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 ... I have a fancy script that I'll post soon that does something like this. It takes the git approach and expands: qemu foo --bar=baz To: qemu-foo --bar=baz Which means that you could do: qemu system-x86_64 -hda foo.img And it'd go to: qemu-system-x86_64 -hda foo.img But there is also a smarter 'run' command that let's you do: qemu run --target=x86_64 -hda foo.img I've made no attempt to unify linux-user. It's a very different executable with a different usage model. My motivation is QOM as I don't want to have command line options to create devices any more. Instead, a front end script will talk to the monitor to setup devices/machines. Regards, Anthony Liguori > > are all equivalent. autotest should easily be able to pass different > -target based on the test being run. >