[libvirt] Cpu Modeling

Eduardo Habkost ehabkost at redhat.com
Thu Sep 22 19:01:01 UTC 2016


Hi!

On Thu, Sep 22, 2016 at 02:47:36PM -0400, Jason J. Herne wrote:
> 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.

I am, but I would like to hear Jiri's feedback in case there's
anything that is still lacking in the new interface.

Additionanl comments below:

> 
> 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

The main problem here is for libvirt to get machine-friendly
error information from QEMU in case the VM fails to start. But if
libvirt avoids starting QEMU based on previously-collected
runnability information, we should be OK.

> - Could be done using query-cpu-model-comparison in the future.

I sent a series adding runnability information to
query-cpu-definitions as well.

> 
> Identifying host model, e.g. "virsh capabilities"
> - query-cpu-model-expansion on "host" with "-M none --enable-kvm"

Correct.

> 
> <cpu mode='host-model'>:
> - simply copy the identified host model
> 
> <cpu mode='host-passthrough'>:
> - "-cpu host"

Correct.

> 
> "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"

Correct.

> 
> 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.

I believe libvirt developers want to change this, because the
current approach is wrong for x86 as well.

> 
> 2. virsh cpu-models {arch} will also use a Qemu invocation to gather cpu
> model
> data.

I believe libvirt can collect this data once, and cache it (like
it does today).

> 
> 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.

I believe the goal is to make cpu_map.xml unnecessary on x86 as
well.

> 
> 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?

I am not sure about this part, because I don't know what are the
existing use cases of cpu-baseline and cpu-compare. But I believe
this shouldn't be a problem as long as the function is not called
very often and/or results are cached by libvirt.

-- 
Eduardo




More information about the libvir-list mailing list