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