On Fri, Jun 24, 2016 at 01:32:32PM +0200, Jiri Denemark wrote: > On Thu, Jun 23, 2016 at 10:18:20 +0100, Daniel P. Berrange wrote: > > On Fri, Jun 17, 2016 at 11:17:47AM +0200, Jiri Denemark wrote: > > > Oh and I completely forgot the most important thing: it makes little > > > sense to add CPUID features that QEMU does not support. It will only > > > allow users to see the features in host CPU capabilities. So if the > > > purpose of these patches is to be able to advertise whether the > > > appropriate perf events are supported on current host, CPU features are > > > not the right way of doing that. I think domain capabilities XML would > > > be the right place to advertise what events are supported. > > > > Nova schedules guests based on the CPU features that the host has, so > > we really do want this to be exposed in the general host capabilities > > XML description of the host CPU. We don't care about running guests > > with this features - we just want to see the host report for them. > > Wouldn't it be more practical to advertise this stuff in a different > manner than? If we report these CPU features in host CPU capabilities > and someone takes the host CPU definition, runs it through > virConnectBaselineCPU to get a guest CPU configuration and uses it to > start a domain, they might be quite surprised that it doesn't work: > > $ ./qemu-system-x86_64 -cpu Skylake-Client,+mbm_total > qemu-system-x86_64: CPU feature mbm-total not found > > On the other hand, running an older QEMU which doesn't understand > features which new QEMU does is not any different. And technically, all > the new features are valid CPU. So take this comment more as something > to thing about the right way to advertise this kind of stuff. Yep, that problem already exists. What is likely needed is a way to ask for a baseline CPU, given a particular choice of machine type and emulator binary. eg similar to how we added the domain capabilities which accepts emulator, arch, machine as parameters. Regards, 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