[Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt
Avi Kivity
avi at redhat.com
Sun Mar 25 16:06:52 UTC 2012
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
More information about the Arch
mailing list