On Wed, Nov 20, 2024 at 10:23:55 +0000, Daniel P. Berrangé wrote:
FYI, I re-ran the sync script after applying this series:
./src/cpu_map/sync_qemu_models_i386.py ../qemu src/cpu_map
and it adds a bunch more CPUs from QEMU git master.
<include filename='x86_GraniteRapids-v1.xml'/>
<include filename='x86_SierraForest.xml'/>
<include filename='x86_SierraForest-v1.xml'/>
+ <include
filename='/var/home/berrange/src/virt/libvirt/src/cpu_map/x86_GraniteRapids-v2.xml'/>
This is a new version added in 9.2.0, while I explicitly wanted to only
add released CPU model, i.e., used 9.1.*. Since 9.2.0 is in rc phase
already I guess I could add this v2 as well.
+ <include
filename='/var/home/berrange/src/virt/libvirt/src/cpu_map/x86_Denverton.xml'/>
+ <include
filename='/var/home/berrange/src/virt/libvirt/src/cpu_map/x86_Denverton-v1.xml'/>
+ <include
filename='/var/home/berrange/src/virt/libvirt/src/cpu_map/x86_Denverton-v2.xml'/>
+ <include
filename='/var/home/berrange/src/virt/libvirt/src/cpu_map/x86_Denverton-v3.xml'/>
+ <include
filename='/var/home/berrange/src/virt/libvirt/src/cpu_map/x86_KnightsMill.xml'/>
This series is adding versioned variants to existing CPU models, while
Denverton and KnightsMill were never supported by libvirt. I don't think
they need to be added (Denverton is an Atom CPU and KnightsMill is some
kind of a dead evolution branch), but we can just add them for
consistency.
</group>
Also it is wierd that it added full paths, rather than relative
paths to index.xml ? This fails when actually run, as we're only
expecting relative paths, and so preprepend the CPU map path
to the absolute path.
The absolute paths are strange, I'll look at it.
Jirka