From mboxrd@z Thu Jan  1 00:00:00 1970
From: Borislav Petkov <bp@alien8.de>
Subject: Re: [PATCH -v2] kvm: Emulate MOVBE
Date: Wed, 17 Apr 2013 16:02:00 +0200
Message-ID: <20130417140200.GE11807@pd.tnic>
References: <20130410123901.46b65169@slackpad>
 <20130410121639.GE17919@redhat.com>
 <20130411001815.GA17544@pd.tnic>
 <20130411142818.GA17919@redhat.com>
 <20130411153733.GE27062@pd.tnic>
 <20130414074107.GD17919@redhat.com>
 <20130414173215.GD20547@pd.tnic>
 <20130416174236.GE5807@redhat.com>
 <20130417110433.GD11807@pd.tnic>
 <20130417133829.GH1682@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Cc: Andre Przywara <andre@andrep.de>, kvm@vger.kernel.org,
	=?utf-8?B?SsO2cmcgUsO2ZGVs?= <joro@8bytes.org>,
	"H. Peter Anvin" <hpa@zytor.com>, x86-ml <x86@kernel.org>
To: Gleb Natapov <gleb@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail.skyhub.de ([78.46.96.112]:34096 "EHLO mail.skyhub.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S966321Ab3DQOCI (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 17 Apr 2013 10:02:08 -0400
Content-Disposition: inline
In-Reply-To: <20130417133829.GH1682@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Wed, Apr 17, 2013 at 04:38:29PM +0300, Gleb Natapov wrote:
> Yes, but it is "good" emulation. You want to have it for performance
> even if host does not have x2apic. x2apic is emulated no matter if
> host cpu has it or not. movbe is different, you want to emulate it
> only if your guest requires it.

It sounds to me you want to have feature bits which are *explicitly*
enabled on the command line nandled differently in qemu.

Let me elaborate:

1. x2apic is always enabled in qemu and will be reported through
KVM_GET_SUPPORTED_CPUID, no matter whether emulated or not.

2. movbe, which got enabled on the command line through "-cpu
n270,+movbe" will be enabled for this specific guest only. Anything else
*without* "+movbe" on the command line, will not get the emulation.

Those 2 categories or am I missing a third one?

> > How's that? Too simple?
> As I said this will filter x2apic on machines which host cpu does not
> support it. This is not what we want.

Right, so basically we want to handle features which were explicitly
enabled only for this guest as private, only relevant to this particular
guest run.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--