[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] qemu-iotests: look for qemu-iotests-$ARCH
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH] qemu-iotests: look for qemu-iotests-$ARCH |
Date: |
Wed, 08 Jul 2009 13:09:14 +0200 |
User-agent: |
Thunderbird 2.0.0.21 (X11/20090320) |
Christoph Hellwig schrieb:
> On Wed, Jul 08, 2009 at 10:34:35AM +0200, Kevin Wolf wrote:
>> Christoph Hellwig schrieb:
>>> Look for the binary as installed by qemu make install instead of
>>> requiring the qemu symlink. Note that we need a couple of regular
>>> expressions to munge the uname output into the architecture name
>>> qemu expects.
>> I don't completely understand your goal here. Why would you want to use
>> the host architecture for the guest, too? If anything this makes tests
>> behave differently on different hosts. If, say, qemu-system-x86_64 is
>> available depends on the configure options rather than on the host. And
>> qemu isn't a symlink AFAIK, but the traditional name of qemu-system-i386
>> (or has this changed recently?).
>
> I did this from the kvm point of view where normally host equals guest
> (modulo differences like i386 vs x86_64). In my installation qemu was a
> symlink, not sure if this was the original or if I did it manually at
> some point.
I'm not sure that the KVM point of view really matters here. I can see
two possible use cases for qemu: Either we just start it up without a
guest OS to do things like a simple savevm, then TCG is just as good. Or
we boot up a guest OS, then we obviously need the architecture matching
the guest, not the host.
> So what method of finding a suitable qemu binary do you suggest instead?
> I'm pretty open for doing anything that works.
Maybe something like trying qemu-system-x86_64, then qemu-kvm, then
qemu? We could use i386 guests on every host then. If it's accelerated
with KVM, kqemu or not at all doesn't really matter.
Kevin