[Qemu-devel] -cpu check, rdtscp and AMD KVM

[Qemu-devel] -cpu check, rdtscp and AMD KVM

[Paolo Bonzini]

Eduardo,

running QEMU 2.5 on SVM causes a warning because rdtscp is not supported
by KVM.  While I can fix it, that leaves a warning on all existing kernels.

What do you think is the best way forward?

Paolo

Re: [Qemu-devel] -cpu check, rdtscp and AMD KVM

[Eduardo Habkost]

On Thu, Nov 12, 2015 at 11:53:44AM +0100, Paolo Bonzini wrote:
> Eduardo,
> 
> running QEMU 2.5 on SVM causes a warning because rdtscp is not supported
> by KVM.  While I can fix it, that leaves a warning on all existing kernels.

You mean when using Opteron_G2 or newer, right? qemu64 and kvm64
don't have rdtscp enabled.

> 
> What do you think is the best way forward?

To simply remove rdtscp from all Opteron_G* models?

-- 
Eduardo

Re: [Qemu-devel] -cpu check, rdtscp and AMD KVM

[Paolo Bonzini]

On 12/11/2015 16:25, Eduardo Habkost wrote:
> On Thu, Nov 12, 2015 at 11:53:44AM +0100, Paolo Bonzini wrote:
>> Eduardo,
>>
>> running QEMU 2.5 on SVM causes a warning because rdtscp is not supported
>> by KVM.  While I can fix it, that leaves a warning on all existing kernels.
> 
> You mean when using Opteron_G2 or newer, right? qemu64 and kvm64
> don't have rdtscp enabled.
> 
>> What do you think is the best way forward?
> 
> 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.

Paolo

Re: [Qemu-devel] -cpu check, rdtscp and AMD KVM

[Eduardo Habkost]

On Thu, Nov 12, 2015 at 04:58:37PM +0100, Paolo Bonzini wrote:
> On 12/11/2015 16:25, Eduardo Habkost wrote:
> > On Thu, Nov 12, 2015 at 11:53:44AM +0100, Paolo Bonzini wrote:
> >> Eduardo,
> >>
> >> running QEMU 2.5 on SVM causes a warning because rdtscp is not supported
> >> by KVM.  While I can fix it, that leaves a warning on all existing kernels.
> > 
> > You mean when using Opteron_G2 or newer, right? qemu64 and kvm64
> > don't have rdtscp enabled.
> > 
> >> What do you think is the best way forward?
> > 
> > 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? 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.

-- 
Eduardo

Re: [Qemu-devel] -cpu check, rdtscp and AMD KVM

[Paolo Bonzini]

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.

> 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.

Is this correct?

Paolo

Re: [Qemu-devel] -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