On Fri, Sep 23, 2016 at 02:05:59PM +0200, Jiri Denemark wrote:
> 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.
Yeah, I still need to implement it.
>
> 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.
I believe query-qmp-schema and/or query-commands can be used for
that.
But you may still have the command returning the error above if
it is simply not implemented in that architecture. I will start a
qemu-devel thread to look for better solutions.
>
> > <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.
That's interesting to know. I was often confused about the
interfaces that seem to be generic (not depend on a specific QEMU
binary) but seemed to depend on information from the QEMU binary
(virsh capabilities and virsh cpu-models). It looks like I was
looking at the wrong commands.
>
> > 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.
device-list-properties should return all the properties you can
set. But I recommend that you don't make libvirt set any of the
properties in the list unless: 1) you know what it does; or 2) it
is returned by a query-cpu-model-expansion call.
>
> > 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.
Right now the commands are available only on s390x. I plan to
have them implemented in x86 before QEMU 2.8 is out.
--
Eduardo
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list