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

[Lucas Meneghel Rodrigues <lmr@redhat.com>]

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.