All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Borislav Petkov" <bp@alien8.de>
To: "Eduardo Habkost" <ehabkost@redhat.com>
Cc: "Borislav Petkov" <bp@alien8.de>,
	"LKML" <linux-kernel@vger.kernel.org>,
	"Borislav Petkov" <bp@suse.de>, "H. Peter Anvin" <hpa@zytor.com>,
	"Gleb Natapov" <gleb@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Andre Przywara" <andre@andrep.de>,
	"Joerg Roedel" <joro@8bytes.org>, "X86 ML" <x86@kernel.org>,
	"KVM" <kvm@vger.kernel.org>,
	qemu-devel@nongnu.org
Subject: Re: [PATCH 1/6] kvm: Add KVM_GET_EMULATED_CPUID
Date: Tue, 24 Sep 2013 11:57:00 +0200 (CEST)	[thread overview]
Message-ID: <2f5d83d4d90ba9c5930f099d6f73e61b.squirrel@www.skyhub.de> (raw)
In-Reply-To: <20130923162856.GC7264@otherpad.lan.raisama.net>

On Mon, September 23, 2013 6:28 pm, Eduardo Habkost wrote:
> On Sun, Sep 22, 2013 at 04:44:50PM +0200, Borislav Petkov wrote:
>> From: Borislav Petkov <bp@suse.de>
>>
>> Add a kvm ioctl which states which system functionality kvm emulates.
>> The format used is that of CPUID and we return the corresponding CPUID
>> bits set for which we do emulate functionality.
>
> Let me check if I understood the purpose of the new ioctl correctly: the
> only reason for GET_EMULATED_CPUID to exist is to allow userspace to
> differentiate features that are native or that are emulated efficiently
> (GET_SUPPORTED_CPUID) and features that are emulated not very
> efficiently (GET_EMULATED_CPUID)?

Not only that - emulated features are not reported in CPUID so they
can be enabled only when specifically and explicitly requested, i.e.
"+movbe". Basically, you want to emulate that feature for the guest but
only for this specific guest - the others shouldn't see it.

> If that's the case, how do we decide how efficient emulation should be,
> to deserve inclusion in GET_SUPPORTED_CPUID? I am guessing that the
> criterion will be: if enabling it doesn't risk making performance worse,
> it can get in GET_SUPPORTED_CPUID.

Well, in the MOVBE case, supported means, the host can execute this
instruction natively. Now, you guys say you can emulate x2apic very
efficiently and I'm guessing emulating x2apic doesn't bring any
emulation overhead, thus SUPPORTED_CPUID.

But for single instructions or group of instructions, the distinction
should be very clear.

At least this is how I see it but Gleb probably can comment too.

Thanks.

-- 
Regards/Gruss,
Boris.


WARNING: multiple messages have this Message-ID (diff)
From: "Borislav Petkov" <bp@alien8.de>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: KVM <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Joerg Roedel <joro@8bytes.org>, X86 ML <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	qemu-devel@nongnu.org, Andre Przywara <andre@andrep.de>,
	Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
	Paolo Bonzini <pbonzini@redhat.com>, Borislav Petkov <bp@suse.de>
Subject: Re: [Qemu-devel] [PATCH 1/6] kvm: Add KVM_GET_EMULATED_CPUID
Date: Tue, 24 Sep 2013 11:57:00 +0200 (CEST)	[thread overview]
Message-ID: <2f5d83d4d90ba9c5930f099d6f73e61b.squirrel@www.skyhub.de> (raw)
In-Reply-To: <20130923162856.GC7264@otherpad.lan.raisama.net>

On Mon, September 23, 2013 6:28 pm, Eduardo Habkost wrote:
> On Sun, Sep 22, 2013 at 04:44:50PM +0200, Borislav Petkov wrote:
>> From: Borislav Petkov <bp@suse.de>
>>
>> Add a kvm ioctl which states which system functionality kvm emulates.
>> The format used is that of CPUID and we return the corresponding CPUID
>> bits set for which we do emulate functionality.
>
> Let me check if I understood the purpose of the new ioctl correctly: the
> only reason for GET_EMULATED_CPUID to exist is to allow userspace to
> differentiate features that are native or that are emulated efficiently
> (GET_SUPPORTED_CPUID) and features that are emulated not very
> efficiently (GET_EMULATED_CPUID)?

Not only that - emulated features are not reported in CPUID so they
can be enabled only when specifically and explicitly requested, i.e.
"+movbe". Basically, you want to emulate that feature for the guest but
only for this specific guest - the others shouldn't see it.

> If that's the case, how do we decide how efficient emulation should be,
> to deserve inclusion in GET_SUPPORTED_CPUID? I am guessing that the
> criterion will be: if enabling it doesn't risk making performance worse,
> it can get in GET_SUPPORTED_CPUID.

Well, in the MOVBE case, supported means, the host can execute this
instruction natively. Now, you guys say you can emulate x2apic very
efficiently and I'm guessing emulating x2apic doesn't bring any
emulation overhead, thus SUPPORTED_CPUID.

But for single instructions or group of instructions, the distinction
should be very clear.

At least this is how I see it but Gleb probably can comment too.

Thanks.

-- 
Regards/Gruss,
Boris.

  reply	other threads:[~2013-09-24  9:57 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-22 14:44 [PATCH 0/6] kvm: Emulate MOVBE, v3 Borislav Petkov
2013-09-22 14:44 ` [PATCH 1/6] kvm: Add KVM_GET_EMULATED_CPUID Borislav Petkov
2013-09-23 16:28   ` Eduardo Habkost
2013-09-23 16:28     ` [Qemu-devel] " Eduardo Habkost
2013-09-23 16:28     ` Eduardo Habkost
2013-09-24  9:57     ` Borislav Petkov [this message]
2013-09-24  9:57       ` [Qemu-devel] " Borislav Petkov
2013-09-24 10:04       ` Gleb Natapov
2013-09-24 10:04         ` [Qemu-devel] " Gleb Natapov
2013-09-26 14:19         ` Eduardo Habkost
2013-09-26 14:19           ` [Qemu-devel] " Eduardo Habkost
2013-09-26 18:55           ` Borislav Petkov
2013-09-26 18:55             ` [Qemu-devel] " Borislav Petkov
2013-09-26 19:20             ` Eduardo Habkost
2013-09-26 19:20               ` [Qemu-devel] " Eduardo Habkost
2013-09-26 20:32               ` Borislav Petkov
2013-09-26 20:32                 ` [Qemu-devel] " Borislav Petkov
2013-09-26 20:32                 ` Borislav Petkov
2013-09-27 14:21                 ` Eduardo Habkost
2013-09-27 14:21                   ` [Qemu-devel] " Eduardo Habkost
2013-09-28 10:49                   ` Borislav Petkov
2013-09-28 10:49                     ` [Qemu-devel] " Borislav Petkov
2013-09-30 16:13                     ` Eduardo Habkost
2013-09-30 16:13                       ` [Qemu-devel] " Eduardo Habkost
2013-09-30 16:18                       ` Borislav Petkov
2013-09-30 16:18                         ` [Qemu-devel] " Borislav Petkov
2013-09-22 14:44 ` [PATCH 2/6] kvm, emulator: Use opcode length Borislav Petkov
2013-09-22 14:44 ` [PATCH 3/6] kvm, emulator: Rename VendorSpecific flag Borislav Petkov
2013-09-22 14:44 ` [PATCH 4/6] kvm, emulator: Add initial three-byte insns support Borislav Petkov
2013-10-29  9:50   ` Gleb Natapov
2013-10-29 10:04     ` Borislav Petkov
2013-10-29 10:11       ` Gleb Natapov
2013-09-22 14:44 ` [PATCH 5/6] kvm: Emulate MOVBE Borislav Petkov
2013-09-22 14:44 ` [PATCH 6/6] qemu: Add support for emulated CPU features Borislav Petkov
2013-09-23 17:06   ` Eduardo Habkost
2013-09-23 17:06     ` [Qemu-devel] " Eduardo Habkost
2013-10-29  9:53 ` [PATCH 0/6] kvm: Emulate MOVBE, v3 Gleb Natapov
2013-10-29 10:30   ` Borislav Petkov
2013-10-29 10:35     ` Gleb Natapov
2013-10-29 11:28       ` Borislav Petkov
2013-10-29 11:36         ` Gleb Natapov
2013-10-29 11:53           ` Borislav Petkov
2013-10-29 11:54             ` [PATCH 4/5 -v3.1] kvm, emulator: Add initial three-byte insns support Borislav Petkov
2013-10-29 11:54             ` [PATCH 5/5 -v3.1] kvm: Emulate MOVBE Borislav Petkov
2013-10-30 17:56               ` Paolo Bonzini
2013-10-30 18:03                 ` Borislav Petkov
2013-10-30 18:10 ` [PATCH 0/6] kvm: Emulate MOVBE, v3 Paolo Bonzini
2013-10-30 18:44   ` Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2f5d83d4d90ba9c5930f099d6f73e61b.squirrel@www.skyhub.de \
    --to=bp@alien8.de \
    --cc=andre@andrep.de \
    --cc=bp@suse.de \
    --cc=ehabkost@redhat.com \
    --cc=gleb@redhat.com \
    --cc=hpa@zytor.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.