On Fri, Jun 19, 2015 at 15:43:02 +0100, Daniel P. Berrange wrote: > On Fri, Jun 19, 2015 at 04:36:34PM +0200, Jiri Denemark wrote: > > On Thu, Jun 18, 2015 at 14:41:17 +0100, Daniel P. Berrange wrote: > > > > So either we need to define all existing CPU models in all their > > > > variants used for various machine types and have a mapping between > > > > (model without a version, machine type) to a specific version of the > > > > model (which may be quite hard) or we need to be able to distinguish > > > > between an existing domain and a new domain with no CPU model version. > > > > While host-model and host-passthrough CPU modes are easy because they > > > > are designed to change everytime a domain starts (which means we don't > > > > need to be able to distinguish between existing and new domains), custom > > > > CPU mode are tricky. Currently, the only at least a bit reasonable thing > > > > which came to my mind is to have a new CPU mode, but it still seems > > > > awkward so please share your ideas if you have any. > > > > > > Introducing a new CPU mode feels pretty unpleasant to me. > > > > > > Although it will certainly be tedious work, getting details of all the > > > CPU variants for historical machine types should be doable I think. > > > > Yeah, I also prefer this variant but I was kind of hoping someone would > > come up with a bright idea which would safe me from all the work :-P > > Allow me to introduce you to perl and regexes :-P Haha, I'm afraid it's not as simple since the machine type specific tweaks to CPU models are done in the code, you can't just look at some data structures to get all the variants. Actually, it has changed and it's defined in macros now, but there is another way which does not need a lot of work :-) Using a slightly modified (to produce a bit more condensed output) x86-cpu-model-dump script from Eduardo and some shell scripting around it I fetched all 700+ combinations of CPU models and machine types and differences between subsequent variants of the same CPU model. So this part was not that bad. However, knowing all the details about a guest CPU used by QEMU for a given CPU model on a specific machine type is not enough to enforce ABI stability. Without using -cpu Model,enforce (or an equivalent of checking filtered-features via QMP) QEMU may silently filter features it cannot provide on the current host. Even in case of TCG some features are not supported, e.g., -cpu SandyBridge will always fail to start in enforcing mode. Even doing something ugly and using the enforce mode only for new machine types is not going to work because after a QEMU upgrade new libvirt would be incompatible with older libvirt. That said, I don't really see a way to do all this automatically without an explicit switch in a domain XML. Be it a new CPU mode or an attribute which would request enforcing ABI stability. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list