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
