On Fri, Jun 19, 2015 at 14:27:27 +0200, Daniel Hansel wrote: ... > 1. During start of libvirt daemon QEMU monitor is used to retrieve the > CPU models (i.e. just model names, QEMU handles all other setting like > features, etc.) QEMU is supporting. > 2. The supported CPU models are stored in libvirt's QEMU capabilities > (and stored in the capabilities cache file). These are fine. > 3. Each call of virConnectGetCPUModelNames() (i.e. > qemuConnectGetCPUModelNames()) is retrieving the information from QEMU > capabilities (cached or not) on s390x platform. All other platforms > remain on the currently implemented way to parse the cpu_map.xml. But this is not. virConnectGetCPUModelNames() was not really designed to provide a list of CPUs supported by a specific emulator binary with a specific machine type. Thus, we should keep virConnectGetCPUModelNames always return a list of CPU models known to libvirt. We should use emulator capabilities XML returned by virConnectGetDomainCapabilities to advertise CPU models supported by QEMU for each combination of (binary, arch, machine, accel) including additional stuff such as whether the CPU is the default one, is migratable, is runnable on current host etc. And we should do this on all achitectures, not just s390x. That is, we need to come up with a good XML design which would fit all architectures. > Depending on that implementation all requests to get CPU models (e.g. > for CPU model comparison, CPU model listing) will lead to a more > appropriate result (e.g. if a QEMU binary is exchanged by a QEMU > binary built manually). We may need to provide additional CPU related APIs which would take (binary, arch, machine, accel) into account. But if we are good at reporting relevant data in the emulator capabilities XML, the new APIs may be unnecessary. For example, an app/user can just query the XML for all runnable CPU models instead of comparing every CPU model known to libvirt with a current host. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list