Re: [libvirt] Cpu Modeling

On Thu, Sep 22, 2016 at 14:47:36 -0400, Jason J. Herne wrote: > Testing for runability: > - Simply try to start QEMU with KVM, compat machine, CPU model Yes, if the domain XML explicitly requests a specific CPU model. Additionally, we need to make sure a CPU model chosen by libvirt (host-model) is runnable, but that should be handled by query-cpu-model-expansion. > Identifying host model, e.g. "virsh capabilities" > - query-cpu-model-expansion on "host" with "-M none --enable-kvm" Right, except that it doesn't seem to work on x86_64 now. It's not critical for query-cpu-model-expansion, but do we have an interface we can use to check whether the new commands are supported by a QEMU binary? Trying and checking for {"error": {"class": "GenericError", "desc": "this feature or command is not currently supported"}} is not really possible. At least we'd need a specific error class. > <cpu mode='host-model'>: > - simply copy the identified host model Yes. > <cpu mode='host-passthrough'>: > - "-cpu host" Exactly. ... > 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. Not really, virsh capabilities will still contain data gathered directly from the host hardware. But, we have virsh domcapabilities for displaying data tight to a specific QEMU binary. Since yesterday afternoon we have support for displaying CPU related data in the domain capabilities XML; see http://libvirt.org/formatdomaincaps.html#elementsCPU The host-model part of the XML will show the result of query-cpu-model-expansion on "host" model, or the result of querying the hardware directly if we can't ask QEMU for that (which is the current state). > 2. virsh cpu-models {arch} will also use a Qemu invocation to gather > cpu model data. No, virsh cpu-models will just list CPU models supported by libvirt (or an empty list if libvirt supports all models supported by QEMU). The CPU model data from QEMU can be found in domain capabilities XML. > 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. Even if we switch some CPU operations to work through QEMU, we may still need to use the cpu_map.xml file for some other operations, or other hypervisor driver. It all depends on what we need to do for a given architecture. For example, ARM does not use cpu_map.xml at all even now. Slightly related, I don't think we have a way to list CPU features supported by QEMU over QMP, do we? "-cpu ?" will show them all, but I couldn't find a QMP command that would give me the same list. > 4. virsh cpu-baseline and cpu-compare will now invoke qemu directly as > well. Perhaps, but before we can do that, we'll probably need to come up with new APIs. It don't think it's critical, though. > 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. Well, IIUC the new commands are not supported on any other architecture right now, are they? Anyway, I don't think we need to switch everything at the same time. If we have a way to detect what commands are supported for a specific QEMU binary, we can implement the code in libvirt and use when we can or falling back to the current way. Jirka