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