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

[Anthony Liguori <anthony@codemonkey.ws>]

On 09/13/2011 02:31 PM, Blue Swirl wrote:
> On Mon, Sep 12, 2011 at 9:05 PM, Anthony Liguori<anthony@codemonkey.ws>  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<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
>
> 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.

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