On 03/25/2012 03:26 PM, Anthony Liguori wrote:
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.
Agree.
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.
Sure. We can have something like # default machine's westmere qemu -cpu westmere # pc-1.0's westmere qemu -M pc-1.0 -cpu westmere # pc-1.0's westmere, without nx-less qemu -M pc-1.0 -cpu westmere,-nx # specify everything in painful detail qemu -cpu vendor=Foo,family=17,model=19,stepping=3,maxleaf=12,+fpu,+vme,leaf10eax=0x1234567,+etc -- error compiling committee.c: too many arguments to function