[libvirt] -cpu check, rdtscp and AMD KVM

[Eduardo Habkost]

(CCing libvir-list)

On Thu, Nov 12, 2015 at 05:35:59PM +0100, Paolo Bonzini wrote:
> On 12/11/2015 17:27, Eduardo Habkost wrote:
> >> > > To simply remove rdtscp from all Opteron_G* models?
> > > 
> > > Not sure this is the right thing to do...  Real hardware has it, and
> > > going forward KVM will provide it.
> > 
> > Do you see any alternative?
> 
> Live with the warning, and document it in the release notes.

That's an option too. But it will cause breakage when upgrading
the host kernel, and force users to live with a broken setup
because we don't provide CPU models that work.

In addition to providing CPU models that work, I believe it's
better to make QEMU CPU models match what is already happening in
practice with the existing VMs.

> 
> > We need AMD CPU models that can run
> > out of the box using today's kernels. As no existing VMs running
> > Opteron_G* on AMD CPUs have rdtscp, I believe it makes sense to
> > just define Opteron_G* without rdtscp.
> > 
> > When we add SVM rdtscp support to KVM, we can add new
> > "Opteron_G[2-5]-rdtscp" CPU models.
> 
> Makes sense too.
> 
> However, I'm a bit afraid of the interaction with libvirt. Right now,
> libvirt has rdtscp in the description.  If we remove it from libvirt,
> libvirt will start adding +rdtscp to the QEMU CPU command line option,
> so our change will be moot.  And if we do not remove it from libvirt,
> libvirt will not be able to start a VM with rdtscp on a fixed kernel.

The former is not true (the change won't be moot). The latter
seems true.

AFAIK, the presence of rdtscp in cpu_map.xml only does two
things:

* Makes libvirt never use "-cpu Opteron_G2,+rdtscp" even if the
  user explicitly asked for rdtscp (which is a libvirt bug that
  should be fixed);
* Makes libvirt refuse to run Opteron_G2 in hosts that lack
  rdtscp (which is also a libvirt bug, because it's checking host
  CPUID directly instead of GET_SUPPORTED_CPUID; libvirt must let
  QEMU check if the feature is really available).

-- 
Eduardo