On Tue, Sep 13, 2011 at 8:16 PM, Anthony Liguori <anth...@codemonkey.ws> wrote: > On 09/13/2011 02:31 PM, Blue Swirl wrote: >> >> On Mon, Sep 12, 2011 at 9:05 PM, Anthony Liguori<anth...@codemonkey.ws> >> 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<a...@redhat.com>: >>>>>>> >>>>>>>> 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.
OK, so qemu-img etc. will be also wrapped by this tool? It looks like the phrase "just a hobby, won't be big and professional like libvirt" could be used again ;-). > > 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. >>>> >>> >>> >>> > >
