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
