Re: [libvirt] [RFC] qemu: Redesigning guest CPU configuration
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