Hi Jiri & Eduardo,
You might remember a discussion with David Hildenbrand of IBM on the Qemu
mailing list regarding a new Qemu<->Libvirt interface for cpu modeling. I am
picking up this work from David and I wanted to confirm that we are
still on the
same page as to the direction of that interface.
For your reference:
https://www.redhat.com/archives/libvir-list/2016-June/thread.html#01413
https://lists.gnu.org/archive/html/qemu-devel/2016-09/threads.html#00489
The first link is to the discussion you were directly involved in. The
second
link is to the final patch set posted to qemu-devel. The cover letter
gives a
good overview of the interface added to Qemu and the proposed use-case for
Libvirt to use this new cpu modeling support. I'll paste in the most
relevant
section for your convenience:
--------------------------------Libvirt usecase----------------------------
Testing for runability:
- Simply try to start QEMU with KVM, compat machine, CPU model
- Could be done using query-cpu-model-comparison in the future.
Identifying host model, e.g. "virsh capabilities"
- query-cpu-model-expansion on "host" with "-M none --enable-kvm"
<cpu mode='host-model'>:
- simply copy the identified host model
<cpu mode='host-passthrough'>:
- "-cpu host"
"virsh cpu-baseline":
- query-cpu-model-baseline on two models with "-M none"
"virsh cpu-compare":
- query-cpu-model-comparison on two models with "-M none"
There might be some cenarios where libvirt wants to convert another CPU
model to a static variant, this can be done using query-cpu-model-expansion
---------------------------------------------------------------------------
Now that I've hopefully refreshed your memory :) I just want to make
sure that
you are still on-board with this plan. I realize that this new approach does
things differently than Libvirt does today for other platforms. Especially
x86_64. The big differences are as follows:
1. We will invoke qemu to gather the host cpu data used for virsh
capabilities.
Today this data seems to be collected directly from the host hardware
for most
(all?) architectures.
2. virsh cpu-models {arch} will also use a Qemu invocation to gather cpu
model
data.
3. Most architectures seem to use a "map" (xml file containing cpu model
data
that ships with Libvirt) to satisfy #1 and #2 above. Our new method does
not use
this map as it gets all of the data directly from Qemu.
4. virsh cpu-baseline and cpu-compare will now invoke qemu directly as well.
Note: I'm not sure exactly how much all of this will apply just to s390 with
other architectures moving over to the new interface if/when they want
to. Or if
we will want to change all architectures to this new interface at the
same time.
Any guidance?
Thanks for your time and consideration.
--
-- Jason J. Herne (jjherne@xxxxxxxxxxxxxxxxxx)
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list