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