Re: [Qemu-devel] [PATCH] PPC: Fix via-cuda memory registration

[Avi Kivity <avi@redhat.com>]

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<avi@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.

-- 
error compiling committee.c: too many arguments to function