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