On 9 April 2015 at 09:30, Michal Privoznik mpriv...@redhat.com wrote:
Dear list,
when trying to solve this bug [1] I've realized qemu is not reporting a
list of supported architectures for given binary. I mean, we do have
'query-target' but as I understand it it merely reports only the default
architecture. For instance for qemu-system-i386 I get 'i386', for
-x86_64 I get 'x84_64'. However, other binaries like -ppc or -ppc64 can
run other architectures like ppc, ppcle, ppc64, ppc64le and so on.
Some of these I think are more properties of the guest image than
the CPU/QEMU. For instance the fact that you can run both big and
little endian PPC images on qemu-system-ppc64 is just because that's
how the CPU works; from QEMU's point of view there's not much difference
between a kernel that sets the LE flag on bootup and one that doesn't.
(This is a slight simplification, but not I think a misleading one.)
There's also the 64-bit variants of QEMU still support all the 32
bit CPUs, which is why x86_64 will run all the i386 CPUs, ppc64
will run the ppc CPUs, and aarch64 will run the arm CPUs.
(That last one doesn't look from the patch you reference like it's
in your table of equivalents, incidentally.)
So I believe my question is, now that we have a binary capable of
running multiple architectures (and an architecture capable of being run
by several binaries) what is the best way to compute the table?
Well, what's your definition of architecture? QEMU's definition
is probably not the same as yours :-)
Personally I'd be more inclined to say identify the *machine*
you want to run on and the *cpu* you want to use, then check that
the executable supports that machine and cpu.
-- PMM
