john cooper wrote: > > I foresee wanting to iterate over the models and pick the latest one > > which a host supports - on the grounds that you have done the hard > > work of ensuring it is a reasonably good performer, while "probably" > > working on another host of similar capability when a new host is made > > available. > > That's a fairly close use case to that of safe migration > which was one of the primary motivations to identify > the models being discussed. Although presentation and > administration of such was considered the domain of management > tools. My hypothetical script which iterates over models in that way is a "management tool", and would use qemu to help do its job. Do you mean that more powerful management tools to support safe migration will maintain _their own_ processor model tables, and perform their calculations using their own tables instead of querying qemu, and therefore not have any need of qemu's built in table? If so, I favour more strongly Anthony's suggestion that the processor model table lives in a config file (eventually), as that file could be shared between management tools and qemu itself without duplication. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
