Apps like virt-manager want access to the cpu_map.xml, so they can show a pretty list of CPU models to the user.
Right now virtinst/virt-manager is hardcoded to look in /usr/share/libvirt/cpu_map.xml, but obviously that a) is fragile b) is broken in the remote case.
There should be an API to expose cpu_map.xml. Maybe this is just another call for 'please export XML values in the capabilities XML' or similar
Jiri, would this be a useful addition to the work you're doing with CPU modeling?
I don't think we should extend the capabilities XML, since it is getting rather huge already. We could easily add some new APIs for fetching data though.
I think this is one of the things that would fit nicely in a new API for getting emulator capabilities. That would provide a list of CPU models supported by given emulator (in addition to other emulator specific capabilities). And we could perhaps add APIs to expand a CPU model into a list of all CPU features the model supports.
Does the just-added flag extension to virConnectBaselineCPU get us where we want, or is it only part of the solution?
That will let you learn all features associated with a given model name, but does not necessarily let you know all model names that have associated features.
Upstream nowadays has virConnectGetCPUModelNames which solves one part of the problem, virConnectBaselineCPU solves VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES.
But there's still no way to have libvirt tell us about all possible feature flags for enumerating in virt-manager. To provide the current UI with a list of features and a checkbox. While people don't need to mess with this much/ever, for things like x2apic which still aren't the default, people want to turn them on.
virt-manager doesn't need the feature output anymore, so the new API is sufficient. Closing this. If anyone else needs the extended features I mention in Comment #5, please open a new bug