When looking for a QEMU binary suitable for running ppc64le guests
we have to take into account the fact that we use the QEMU target
as key for the hash, so direct comparison is not good enough:
normalize everything that can run on the ppc64 target to
VIR_ARCH_PPC64 instead.
This approach was already used in virQEMUCapsFindBinaryForArch(),
and I've added a comment there to clarify why it's needed.
Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=1260753
---
src/qemu/qemu_capabilities.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 4ad1bdb..a06141e 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -699,6 +699,7 @@ virQEMUCapsFindBinaryForArch(virArch hostarch,
const char *archstr;
char *binary;
+ /* qemu-system-ppc64 can run both ppc64 and ppc64le guests */
if (ARCH_IS_PPC64(guestarch))
archstr = virQEMUCapsArchToString(VIR_ARCH_PPC64);
else
@@ -3791,6 +3792,10 @@ virQEMUCapsCacheLookupByArch(virQEMUCapsCachePtr cache,
virQEMUCapsPtr ret = NULL;
struct virQEMUCapsSearchData data = { .arch = arch };
+ /* QEMU's ppc64 target can run both ppc64 and ppc64le guests */
+ if (ARCH_IS_PPC64(data.arch))
+ data.arch = VIR_ARCH_PPC64;
+
virMutexLock(&cache->lock);
ret = virHashSearch(cache->binaries, virQEMUCapsCompareArch, &data);
VIR_DEBUG("Returning caps %p for arch %s", ret, virArchToString(arch));
The virQEMUCapsFindBinaryForArch metho already has a bunch of logic to
deal with fact that one binary can support multiple different
architectures. For example, x86_64 can support i686. It looks like we
hit the same problem as ppc64/ppc64le in that case and you have not
handled it here. It would be desirable to avoid having to have the same
compat logic in two places too.
Regards,
Daniel
--
|: