[libvirt] Cpu Modeling

[Jiri Denemark]

On Wed, Oct 12, 2016 at 13:55:49 -0400, Jason J. Herne wrote:
> In order to properly obtain the host cpu model data for virsh
> capabilities on s390 we will need to run a Qemu process. There is no
> precedent for doing this in a cpu connection driver today.

There are two reasons for this:

1) it was not required so far
2) it doesn't belong to the CPU driver

> 1. The s390 cpu connection driver (src/cpu/cpu_s390.c) can just
> privately make use of the default Qemu binary and the appropriate qmp
> calls can be made to get the model name and possibly features.

No, the CPU driver is supposed to do generic stuff independently on any
hypervisor.

> 2. We can extend the existing interface somehow so all archs could
> make use of a hypervisor instance for nodeData() and decode()
> operations. Perhaps a new set of callbacks? nodeDataWithHypervisor(),
> decodeWithHypervisor() ?

Why? The hypervisor code that calls CPU driver APIs can just decide to
do something else for certain architectures.

> I'm trying to get the host cpu model for virCapsPtr caps, as it is
> filled in via virQEMUCapsInit --> virQEMUCapsInitCPU. And subsequently
> referenced for the output of virsh capabilities and copied into
> qemuCaps for reference by virsh domcapabilities.

Anyway, host CPU capabilities in virCapsPtr is not supposed to contain
the CPU description queried from QEMU. If we have no generic code to
detect host CPU ourselves, we should just keep host CPU model empty.

The host CPU model queried from QEMU should be placed in virQEMUCapsPtr.
When probing QEMU, we cache data we get from QEMU and the host CPU model
is supposed to be computed virQEMUCapsInitHostCPUModel from the cached
data. (Currently, the function copies the model from virCapsPtr, but
that's only because we don't query QEMU for the right stuff yet.)

Jirka