On 03/11/2012 04:12 PM, Anthony Liguori wrote:
This discussion isn't about whether QEMU should have a Westmere
processor definition. In fact, I think I already applied that patch.
It's a discussion about how we handle this up and down the stack.
The question is who should define and manage CPU compatibility. Right
now QEMU does to a certain degree, libvirt discards this and does it's
own thing, and VDSM/ovirt-engine assume that we're providing something
and has built a UI around it.
What I'm proposing we consider: have VDSM manage CPU definitions in
order to provide a specific user experience in ovirt-engine.
We would continue to have Westmere/etc in QEMU exposed as part of the
user configuration. But I don't think it makes a lot of sense to have
to modify QEMU any time a new CPU comes out.
We have to. New features often come with new MSRs which need to be live
migrated, and of course the cpu flags as well. We may push all these to
qemu data files, but this is still qemu. We can't let a management tool
decide that cpu feature X is safe to use on qemu version Y.