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. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list