From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55447)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Chris.Friesen@windriver.com>) id 1b5wtD-00027R-FD
	for qemu-devel@nongnu.org; Thu, 26 May 2016 11:08:00 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <Chris.Friesen@windriver.com>) id 1b5wt9-0000zx-T2
	for qemu-devel@nongnu.org; Thu, 26 May 2016 11:07:59 -0400
Received: from mail.windriver.com ([147.11.1.11]:57911)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Chris.Friesen@windriver.com>) id 1b5wt9-0000z7-Ks
	for qemu-devel@nongnu.org; Thu, 26 May 2016 11:07:55 -0400
Message-ID: <57470378.4050402@windriver.com>
Date: Thu, 26 May 2016 08:08:56 -0600
From: Chris Friesen <chris.friesen@windriver.com>
MIME-Version: 1.0
References: <574685F4.8070304@windriver.com>
	<20160526104154.GC40539@orkuz.home>
In-Reply-To: <20160526104154.GC40539@orkuz.home>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [libvirt] inconsistent handling of "qemu64" CPU
 model
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: libvir-list@redhat.com, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

On 05/26/2016 04:41 AM, Jiri Denemark wrote:

> The qemu64 CPU model contains svm and thus libvirt will always consider
> it incompatible with any Intel CPUs (which have vmx instead of svm). On
> the other hand, QEMU by default ignores features that are missing in the
> host CPU and has no problem using qemu64 CPU, the guest just won't see
> some of the features defined in qemu64 model.
>
> In your case, you should be able to use
>
>      <cpu mode'custom' match='exact'>
>          <model>qemu64</model>
>          <feature name='svm' policy='disable'/>
>      </cpu>
>
> to get the same CPU model you'd get by default (if not, you may need to
> also add <feature name='vmx' policy='require'/>).
>
> Alternatively
>
>      <cpu mode'custom' match='exact'>
>          <model>qemu64</model>
>          <feature name='svm' policy='force'/>
>      </cpu>
>
> should work too (and it would be better in case you use it on an AMD
> host).

It's actually OpenStack that is setting up the XML, not me, so I'd have to 
special-case the "qemu64" model and it'd get ugly. :)

The question remains, why is "qemu64" okay when used implicitly but not 
explicitly?  I would have expected them to behave the same.


> But why you even want to use qemu64 CPU in a domain XML explicitly? If
> you're fine with that CPU, just let QEMU use a default one. If not, use
> a CPU model that fits your host/needs better.

Working around another issue would be simpler/cleaner if I could just explicitly 
set the model to qemu64.

Chris