On 03/25/2012 08:21 AM, Avi Kivity wrote:
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.
I think QEMU should own CPU definitions. I think a management tool should have the choice of whether they are used though because they are a policy IMHO. It's okay for QEMU to implement some degree of policy as long as a management tool can override it with a different policy. Regards, Anthony Liguori