On Fri, Sep 13, 2013 at 03:45:58PM -0600, Eric Blake wrote: > On 09/13/2013 03:06 PM, Eric Blake wrote: > > On 09/13/2013 02:58 PM, Eric Blake wrote: > >> On 09/11/2013 08:13 AM, Giuseppe Scrivano wrote: > >> > >> I tweaked this some during my testing of NULL models; but don't think we > >> need to make virsh expose NULL models to the command line, so I'm not > >> changing this. > >> > >> ACK with this squashed in (oh, I just noticed my emacs' > >> copyright-checker kicked in for my edits; I wonder how many other files > >> you touched that could use an updated copyright): > >> > > > > Blah. I get this far, where things are finally testable, and see: > > > > # tools/virsh cpu-models x86_64 > > 2013-09-13 21:04:43.332+0000: 16843: error : cpuMapLoad:121 : internal > > error: cannot find CPU map for x86_64 architecture > > error: failed to get CPU model names > > error: internal error: cannot find CPU map for x86_64 architecture > > > > I'm now debugging whether it was one of the patches I modified, or a > > flaw in your original patch. > > Jiri helped me on IRC. The list of arch names in 'virsh capabilities' > is from a canonical list; but the list of arch names in > /usr/share/libvirt/cpu_map.xml is a list of drivers (which can support > one _or more than one_ canonical architecture). More precisely: > > $ grep 'arch ' /usr/share/libvirt/cpu_map.xml > <arch name='x86'> > <arch name='ppc64'> > $ tools/virsh -c test:///default capabilities | grep 'arch ' > <arch name='i686'> > <arch name='i686'> > > this suggests that the 'x86' driver knows how to manage both the 'i686' > and 'x86_64' architectures. So ideally, qemu-system-x86_64 should > support 'virsh cpu-models x86_64' and 'virsh cpu-models i686' with > identical lists (after all, x86_64 chips can run in i686 mode), while > the test driver (which claims support for ONLY i686) might want to fail > for x86_64. Furthermore, with your patches as-is, 'virsh cpu-models > x86' returned a list; but I don't think this is appropriate as that name > is not in the capabilities output. Agreed, that is bad. We need to have the API accepting formal arch names, as defined by virArch enum only, and translate to the names used by the CPU database. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list