re-adding ccs from the cover-letter >>> On 25.11.19 18:20, David Hildenbrand wrote: >>> >>> As soon as dynamic feature groups are used, the CPU model becomes >>> migration-unsafe. Upper layers can expand these models to migration-safe >>> and static variants, allowing them to be migrated. >> >> I really dislike that. I am trying to get rid of the unsafe variants (e.g. >> now >> defaulting to host-model instead of host-passthrough). I do not want to give >> users new ways of hurting themselves. >> > > Please note that this is just on the bare command line. Libvirt and friends > will expand the model and have proper migration in place. What exactly is > your concern in that regard?
What is then the value? libvirt can also use host-model or baselining if necessary. And for the command line this will just add more opportunity to shot yourself in the foot, no? Let me put it this way, I might have misunderstood what you are trying to do here, but if I do not get, then others (e.g. users) will also not get it. Maybe its just the interface or the name. But I find this very non-intuitive e.g. you wrote Get the maximum possible feature set (e.g., including deprecated features) for a CPU definition in the configuration ("everything that could be enabled"): -cpu z14,all-features=off,available-features=on Get all valid features for a CPU definition: -cpu z14,all-features=on What is the point of this? It is either the same as the one before, or it wont be able to start. > >> Unless I misunderstood Eduardo, I think his versioning approach is actually >> better >> in regard to migration, no? >> I z terms, you can still say -cpu z13 which is just an alias to z13v1 z13v2 >> etc. >> Assuming that the version is checked this will be safe. >> > > It‘s even worse AFAIKS. A „-cpu z13“ would dynamically map to whatever is > best on the host. >