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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list