From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53703) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3ZP5-0004e2-Cb for qemu-devel@nongnu.org; Tue, 13 Sep 2011 16:16:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R3ZP4-00084C-7V for qemu-devel@nongnu.org; Tue, 13 Sep 2011 16:16:23 -0400 Message-ID: <4E6FBA09.4080606@codemonkey.ws> Date: Tue, 13 Sep 2011 15:16:09 -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> <4E6E7437.5010900@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH] PPC: Fix via-cuda memory registration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Lucas Meneghel Rodrigues , "qemu-ppc@nongnu.org" , Avi Kivity , qemu-devel Developers On 09/13/2011 02:31 PM, Blue Swirl wrote: > On Mon, Sep 12, 2011 at 9:05 PM, Anthony Liguori wrote: >> 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 > > How would this be better than Avi's version? There isn't even any > compatibility like 'qemu' has with 'qemu' defaulting to 'qemu -system > -target i386'. Because you can then do: $ qemu run -hda foo.img -name bar $ qemu monitor bar info kvm KVM enabled Or you can do: $ sudo qemu setup-nat foo eth0 $ sudo qemu create-vnic foo Created vnic `vnet0' $ qemu run -hda foo.img -net tap,ifname=vnet0 And all sorts of other interesting things. It means a much friendly interface for command line users and much better scriptability. Regards, Anthony Liguori > >> 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. >>> >> >> >>