All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>, Borislav Petkov <bp@suse.de>,
	"H. Peter Anvin" <hpa@zytor.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, libvir-list@redhat.com,
	Jiri Denemark <jdenemar@redhat.com>
Subject: Re: [PATCH 1/6] kvm: Add KVM_GET_EMULATED_CPUID
Date: Thu, 26 Sep 2013 22:32:06 +0200	[thread overview]
Message-ID: <20130926203206.GB10123@pd.tnic> (raw)
In-Reply-To: <20130926192059.GD10924@otherpad.lan.raisama.net>

On Thu, Sep 26, 2013 at 04:20:59PM -0300, Eduardo Habkost wrote:
> Please point me to the code that does this, because I don't see it on
> patch 6/6.

@@ -1850,7 +1850,14 @@ static void filter_features_for_kvm(X86CPU *cpu)
                                                              wi->cpuid_ecx,
                                                              wi->cpuid_reg);
         uint32_t requested_features = env->features[w];
+
+        uint32_t emul_features = kvm_arch_get_emulated_cpuid(s, wi->cpuid_eax,
+                                                                wi->cpuid_ecx,
+                                                                wi->cpuid_reg);
+
         env->features[w] &= host_feat;
+        env->features[w] |= (requested_features & emul_features);

Basically we give the requested_features a second chance here.

If we don't request an emulated feature, it won't get enabled.

> > If you start with "-cpu Haswell", MOVBE
> > will be already set in the host CPUID.
> > 
> > Or am I missing something?
> 
> In the Haswell example, it is unlikely but possible in theory: you would
> need a CPU that supported all features from Haswell except movbe. But
> what will happen if you are using "-cpu n270,enforce" on a SandyBridge
> host?

That's an interesting question: AFAICT, it will fail because MOVBE is
not available on the host, right?

And if so, then this is correct behavior IMHO, or how exactly is the
"enforce" thing supposed to work? Enforce host CPUID?

> Also, we don't know anything about future CPUs or future features
> that will end up on EMULATED_CPUID. The current code doesn't have
> anything to differentiate features that were already included in the
> CPU definition and ones explicitly enabled in the command-line (and I
> would like to keep it that way).

Ok.

> And just because a feature was explicitly enabled in the command-line,
> that doesn't mean the user believe it is acceptable to get it running
> in emulated mode. That's why I propose a new "emulate" flag, to allow
> features to be enabled in emulated mode.

And I think, saying "-cpu ...,+movbe" is an explicit statement enough to
say that yes, I am starting this guest and I want MOVBE emulation.

> Well, x2apic is emulated by KVM, and it is on SUPPORTED_CPUID. Ditto
> for tsc-deadline. Or are you talking specifically about instruction
> emulation?

Basically, I'm viewing this from a very practical standpoint - if I
build a kernel which requires MOVBE support but I cannot boot it in kvm
because it doesn't emulate MOVBE (TCG does now but it didn't before)
I'd like to be able to address that shortcoming by emulating that
instruction, if possible.

And the whole discussion grew out from the standpoint of being able to
emulate stuff so that you can do quick and dirty booting of kernels but
not show that emulation capability to the wide audience since it is slow
and it shouldn't be used and then migration has issues, etc, etc.

But hey, I don't really care all that much if I have to also say
-emulate in order to get my functionality.

Thanks.

-- 
Regards/Gruss,
    Boris.

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

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>,
	libvir-list@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>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jiri Denemark <jdenemar@redhat.com>, Borislav Petkov <bp@suse.de>
Subject: Re: [PATCH 1/6] kvm: Add KVM_GET_EMULATED_CPUID
Date: Thu, 26 Sep 2013 22:32:06 +0200	[thread overview]
Message-ID: <20130926203206.GB10123@pd.tnic> (raw)
In-Reply-To: <20130926192059.GD10924@otherpad.lan.raisama.net>

On Thu, Sep 26, 2013 at 04:20:59PM -0300, Eduardo Habkost wrote:
> Please point me to the code that does this, because I don't see it on
> patch 6/6.

@@ -1850,7 +1850,14 @@ static void filter_features_for_kvm(X86CPU *cpu)
                                                              wi->cpuid_ecx,
                                                              wi->cpuid_reg);
         uint32_t requested_features = env->features[w];
+
+        uint32_t emul_features = kvm_arch_get_emulated_cpuid(s, wi->cpuid_eax,
+                                                                wi->cpuid_ecx,
+                                                                wi->cpuid_reg);
+
         env->features[w] &= host_feat;
+        env->features[w] |= (requested_features & emul_features);

Basically we give the requested_features a second chance here.

If we don't request an emulated feature, it won't get enabled.

> > If you start with "-cpu Haswell", MOVBE
> > will be already set in the host CPUID.
> > 
> > Or am I missing something?
> 
> In the Haswell example, it is unlikely but possible in theory: you would
> need a CPU that supported all features from Haswell except movbe. But
> what will happen if you are using "-cpu n270,enforce" on a SandyBridge
> host?

That's an interesting question: AFAICT, it will fail because MOVBE is
not available on the host, right?

And if so, then this is correct behavior IMHO, or how exactly is the
"enforce" thing supposed to work? Enforce host CPUID?

> Also, we don't know anything about future CPUs or future features
> that will end up on EMULATED_CPUID. The current code doesn't have
> anything to differentiate features that were already included in the
> CPU definition and ones explicitly enabled in the command-line (and I
> would like to keep it that way).

Ok.

> And just because a feature was explicitly enabled in the command-line,
> that doesn't mean the user believe it is acceptable to get it running
> in emulated mode. That's why I propose a new "emulate" flag, to allow
> features to be enabled in emulated mode.

And I think, saying "-cpu ...,+movbe" is an explicit statement enough to
say that yes, I am starting this guest and I want MOVBE emulation.

> Well, x2apic is emulated by KVM, and it is on SUPPORTED_CPUID. Ditto
> for tsc-deadline. Or are you talking specifically about instruction
> emulation?

Basically, I'm viewing this from a very practical standpoint - if I
build a kernel which requires MOVBE support but I cannot boot it in kvm
because it doesn't emulate MOVBE (TCG does now but it didn't before)
I'd like to be able to address that shortcoming by emulating that
instruction, if possible.

And the whole discussion grew out from the standpoint of being able to
emulate stuff so that you can do quick and dirty booting of kernels but
not show that emulation capability to the wide audience since it is slow
and it shouldn't be used and then migration has issues, etc, etc.

But hey, I don't really care all that much if I have to also say
-emulate in order to get my functionality.

Thanks.

-- 
Regards/Gruss,
    Boris.

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

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>,
	libvir-list@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>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jiri Denemark <jdenemar@redhat.com>, Borislav Petkov <bp@suse.de>
Subject: Re: [Qemu-devel] [PATCH 1/6] kvm: Add KVM_GET_EMULATED_CPUID
Date: Thu, 26 Sep 2013 22:32:06 +0200	[thread overview]
Message-ID: <20130926203206.GB10123@pd.tnic> (raw)
In-Reply-To: <20130926192059.GD10924@otherpad.lan.raisama.net>

On Thu, Sep 26, 2013 at 04:20:59PM -0300, Eduardo Habkost wrote:
> Please point me to the code that does this, because I don't see it on
> patch 6/6.

@@ -1850,7 +1850,14 @@ static void filter_features_for_kvm(X86CPU *cpu)
                                                              wi->cpuid_ecx,
                                                              wi->cpuid_reg);
         uint32_t requested_features = env->features[w];
+
+        uint32_t emul_features = kvm_arch_get_emulated_cpuid(s, wi->cpuid_eax,
+                                                                wi->cpuid_ecx,
+                                                                wi->cpuid_reg);
+
         env->features[w] &= host_feat;
+        env->features[w] |= (requested_features & emul_features);

Basically we give the requested_features a second chance here.

If we don't request an emulated feature, it won't get enabled.

> > If you start with "-cpu Haswell", MOVBE
> > will be already set in the host CPUID.
> > 
> > Or am I missing something?
> 
> In the Haswell example, it is unlikely but possible in theory: you would
> need a CPU that supported all features from Haswell except movbe. But
> what will happen if you are using "-cpu n270,enforce" on a SandyBridge
> host?

That's an interesting question: AFAICT, it will fail because MOVBE is
not available on the host, right?

And if so, then this is correct behavior IMHO, or how exactly is the
"enforce" thing supposed to work? Enforce host CPUID?

> Also, we don't know anything about future CPUs or future features
> that will end up on EMULATED_CPUID. The current code doesn't have
> anything to differentiate features that were already included in the
> CPU definition and ones explicitly enabled in the command-line (and I
> would like to keep it that way).

Ok.

> And just because a feature was explicitly enabled in the command-line,
> that doesn't mean the user believe it is acceptable to get it running
> in emulated mode. That's why I propose a new "emulate" flag, to allow
> features to be enabled in emulated mode.

And I think, saying "-cpu ...,+movbe" is an explicit statement enough to
say that yes, I am starting this guest and I want MOVBE emulation.

> Well, x2apic is emulated by KVM, and it is on SUPPORTED_CPUID. Ditto
> for tsc-deadline. Or are you talking specifically about instruction
> emulation?

Basically, I'm viewing this from a very practical standpoint - if I
build a kernel which requires MOVBE support but I cannot boot it in kvm
because it doesn't emulate MOVBE (TCG does now but it didn't before)
I'd like to be able to address that shortcoming by emulating that
instruction, if possible.

And the whole discussion grew out from the standpoint of being able to
emulate stuff so that you can do quick and dirty booting of kernels but
not show that emulation capability to the wide audience since it is slow
and it shouldn't be used and then migration has issues, etc, etc.

But hey, I don't really care all that much if I have to also say
-emulate in order to get my functionality.

Thanks.

-- 
Regards/Gruss,
    Boris.

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

  reply	other threads:[~2013-09-26 20:32 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
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 [this message]
2013-09-26 20:32                 ` 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=20130926203206.GB10123@pd.tnic \
    --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=jdenemar@redhat.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=libvir-list@redhat.com \
    --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.