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'. > 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. >> > > >
