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

[Blue Swirl]

On Tue, Sep 13, 2011 at 8:16 PM, Anthony Liguori <address@hidden> wrote:
> On 09/13/2011 02:31 PM, Blue Swirl wrote:
>>
>> 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'.
>
> Because you can then do:
>
> $ qemu run -hda foo.img -name bar
> $ qemu monitor bar info kvm
> KVM enabled
>
> Or you can do:
>
> $ sudo qemu setup-nat foo eth0
> $ sudo qemu create-vnic foo
> Created vnic `vnet0'
> $ qemu run -hda foo.img -net tap,ifname=vnet0
>
> And all sorts of other interesting things.  It means a much friendly
> interface for command line users and much better scriptability.

OK, so qemu-img etc. will be also wrapped by this tool? It looks like
the phrase "just a hobby, won't be big and professional like libvirt"
could be used again ;-).

>
> Regards,
>
> Anthony Liguori
>
>>
>>> 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.
>>>>
>>>
>>>
>>>
>
>