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