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

[Anthony Liguori <anthony@codemonkey.ws>]

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

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

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