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