On Mon, Sep 12, 2011 at 1:53 PM, Avi Kivity <a...@redhat.com> 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 ... > > are all equivalent. autotest should easily be able to pass different > -target based on the test being run.
Great idea, the original goal of single binary would almost realize. With 'qemu' defaulting to '-system' and '-target i386' we'd also be compatible with previous versions too.
