qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH] PPC: Fix via-cuda memory registration
Date: Tue, 13 Sep 2011 15:16:09 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

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.

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.








reply via email to

[Prev in Thread] Current Thread [Next in Thread]