CCing Christian

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



David

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to