[libvirt] [RFC 0/5] Qemu: s390: Cpu Model Support

Thanks for all your feedback up to this point. We've made some progress on this and we also have a few questions. Please let us know if we're on the right track or if we're off in the weeds on this. Here is what we have so far. Patch #1 updates s390's cpu driver to support some operations needed for cpu model support within Libvirt's existing infrastructure. Patch #2 removes s390's hard coded "host" model string. Jiri thought it made more sense to simply leave this blank. Path #3 adds qmp query-cpu-model-expansion command. Patch #4 probes Qemu's view of the host model (query-cpu-model-expansion), caches the response and uses it to fill in qemuCaps->hostCpuModel. Archs that do not implement query-cpu-model-expansion will continue to fill in qemuCaps->hostCpuModel from caps->host.cpu. Patch #5 updates qemuBuildCpuModelArgStr's VIR_CPU_MODE_HOST_MODEL case. It seems like all archs except PPC64 do not support host model mode. We add an s390 path here and get the guest cpu model from virQEMUCapsGetHostModel() which will get the model name from qemuCaps->hostCpuModel. NOTE: I just realized we'll need need to handle the case where virQEMUCapsGetHostModel returns NULL or the model is NULL or "". We probably should just throw an error and give up in that case. Here is a list of outstanding things to do and some questions. 1. virsh domcapabilities --emulatorbin flag This works today if the command is passed --emulatorbin /usr/bin/qemu-kvm. If no emulatorbin is given then Libvirt seems to choose /usr/bin/qemu-system-s390x my system which does not have kvm enabled. A kvm session is needed for s390 to properly compute the host model. A kvm session is only available for the qemu-kvm binary. Is the answer to tell our users to always supply --emulatorbin with /usr/bin/qemu-kvm argument? Or is there a more user friendly solution to this? 2. virsh baseline and compare support. Both of these commands, for s390 at least, will need to spin up a Qemu session with monitor to compute the result. The only place I see this done today is qemu_capabilities. Rather than blindly duplicate the code, I guess we should carve out some type of api for spinning up a monitor backed Qemu instance, yes? Also, neither compare nor baseline have the --emulatorbin flag. So we'll either need to add them or find an alternate solution. Any thoughts on this? 3.Support host passthrough mode. This essentially just means passing -cpu host to qemu. We know Qemu supports this for s390 today. But Libvirt claims it is not supported due to the following: In virQEMUCapsIsCPUModeSupported, our virt "type" is VIR_DOMAIN_VIRT_QEMU, and not VIR_DOMAIN_VIRT_KVM. virttype comes from domCaps and is set here: qemuConnectGetDomainCapabilities() The relevant code is: if (qemuHostdevHostSupportsPassthroughLegacy() || qemuHostdevHostSupportsPassthroughVFIO()) virttype = VIR_DOMAIN_VIRT_KVM; else virttype = VIR_DOMAIN_VIRT_QEMU; I'll admit, I have not been able to figure out why these checks are failing in my test environment, when I suspect they should be passing. But in my case it seems as though these relate to host device passthrough. How do they apply to cpu model passthrough. What am I missing? Thanks for your time. Collin L. Walling (3): s390: Report blank host model instead of "host" qemu: qmp query-cpu-model-expansion command qemu-caps: Get host model directly from Qemu when available Jason J. Herne (2): s390: Cpu driver support for getModels, update and compare s390: qemu: Support cpu host-model mode src/cpu/cpu_s390.c | 33 +++++++++++++-- src/qemu/qemu_capabilities.c | 88 ++++++++++++++++++++++++++++++++++++++- src/qemu/qemu_command.c | 3 ++ src/qemu/qemu_monitor.c | 28 +++++++++++++ src/qemu/qemu_monitor.h | 19 +++++++++ src/qemu/qemu_monitor_json.c | 98 ++++++++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_monitor_json.h | 6 +++ 7 files changed, 271 insertions(+), 4 deletions(-) -- 1.9.1