On Tue, Jun 21, 2016 at 13:44:31 -0300, Eduardo Habkost wrote: > (CCing libvirt people) > > On Tue, Jun 21, 2016 at 03:02:05PM +0200, David Hildenbrand wrote: > > This is our second attempt to implement CPU models for s390x. We realized > > that we also want to have features exposed via the CPU model. While doing > > that we realized that we want to have a better interface for libvirt. > > Before getting into the details, I would like to clarify how the > following could be accomplished using the new commands: > > Example: > > 1) User configures libvirt with: > <cpu match='exact'> > <model fallback='forbid'>Westmere</model> > <feature policy='require' name='aes'/> > </cpu> > 2) libvirt will translate that to: > "-cpu Westmere,+aes" or "-cpu Westmere,aes=on" > 3) libvirt wants to know if "-cpu Westmere,aes=on" is usable in > the current host, before trying to start the VM. While this is what libvirt currently does, I don't think it's necessary to keep doing that... see below. > > a) "query-cpu-model-expansion" - tell us what the "host" or a migration > > unsafe model looks like. Either falling back to a stable model or > > completely exposing all properties. We are interested in stable models. > > b) "query-cpu-model-comparison" - tell us how two CPU models compare, > > indicating which properties were responsible for the decision. > > c) "query-cpu-model-baseline" - create a new model out of two models, > > taking a requested level of stability into account. This looks like it copies current libvirt APIs, which I think is not a very good idea. Both CPU compare and baseline APIs in libvirt will need to be changed (or rather new APIs with similar functionality added) to become useful. I think we should first focus on making guest CPU configuration work the way it should work. For that I think we need some higher level commands. Let me sum up what libvirt is doing (or will be doing) with guest CPUs... Libvirt supports three guest CPU configuration modes: - host-passthrough -- this is easy, it's just asking for "-cpu host" and no fancy commands are required. - host-model -- for this we need to know what CPU configuration we need to ask for to get as close to the host CPU as possible while being able to ask for the exact same CPU on a different host (after migration). And we need to be able to ask for this at probing time (when libvirtd starts rather than when starting a new domain) using "-machine none,accel=kvm:tcg", that is without actually creating any guest CPU. This is what Eduardo's query-host-cpu QMP command is useful for. In x86 world we could just query the guest CPU after running QEMU with "-cpu host", but that's unusable with "-machine none", which is why another way of getting this info is needed. - custom -- the XML specifies an exact guest CPU configuration. We don't really need to know if that exact CPU is runnable on the current host in advance, we can just try to start the domain, check if the guest CPU matches what we asked for, and we may kill QEMU if the CPU does not meet the specification. Of course, higher level management wants to know a set of host where it can run a given domain for scheduling purposes, but since they logically want to avoid tons of different CPU configs, they would just stick the CPU models predefined by QEMU. Thus giving them a way of checking what CPU models can be run on a given host with a given QEMU (using the unavailable features stuff for query-cpu-definitions usable with "-machine none") should be enough and it's even better than having to ask for every single CPU model, which is what they need to do now. There are configuration options which are somewhere between host-model and custom, but they don't bring more requirements in addition to what both of them needs. This was basically all about starting a new domain. When the domain successfully starts, we need to make sure the guest CPU does not change during save/restore or migration to another host. To achieve this, we need the same checking we need for custom mode, i.e., whether the guest CPU we got is what we asked for. In addition to this, we need a way to ask QEMU what the guest CPU looks like so that we can store it in the domain XML and ask for it during migration. I think all of this should be pretty much architecture agnostic. Of course the actual data would be quite different fro each architecture, but I believe the entry points could fit all. Or did I miss anything? Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list