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

[Blue Swirl]

On Mon, Sep 12, 2011 at 9:05 PM, Anthony Liguori <address@hidden> 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<address@hidden>:
>>>>>
>>>>> > 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.
>>
>
>
>