Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt

[Avi Kivity]

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