From: Jan Kiszka <jan.kiszka@web.de>
To: "\"李春奇 <Arthur Chunqi Li>\"" <yzt356@gmail.com>
Cc: qemu-devel@nongnu.org, kvm <kvm@vger.kernel.org>
Subject: Re: CPU vendor in KVM
Date: Sat, 04 May 2013 10:47:09 +0200 [thread overview]
Message-ID: <5184CB0D.4010004@web.de> (raw)
In-Reply-To: <CABpY8M+ZjO4xKWdV-6F5QJok1qJTd+iW6Q1LPi_3tNUa0=X4Rg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1889 bytes --]
Please don't top-post.
On 2013-05-04 10:45, 李春奇 <Arthur Chunqi Li> wrote:
> But will the difference between the vendor ID and family number cause
> confusion to the OS in VM?
The confusion is not yet clear to me. About which "-cpu ..." were you
talking?
Jan
>
> On Sat, May 4, 2013 at 4:05 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
>> On 2013-05-04 09:50, 李春奇 <Arthur Chunqi Li> wrote:
>>> Hi Jan and All,
>>> I find that when enable KVM with qemu, vendor ID of simulated CPU will be
>>> set the same as host, but other features such as level, family, model,
>>> stepping are not changed. This may bring out a confusing result, the
>>> simulated CPU has a vendor name of "GenuineIntel" but with family number
>>> "16".
>>>
>>> I disabled the related code in function cpu_x86_find_by_name:
>>> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
>>> index e2302d8..df0e82e 100644
>>> --- a/target-i386/cpu.c
>>> +++ b/target-i386/cpu.c
>>> @@ -1295,7 +1295,8 @@ static int cpu_x86_find_by_name(x86_def_t
>>> *x86_cpu_def, const char *name)
>>> * KVM's sysenter/syscall emulation in compatibility mode and
>>> * when doing cross vendor migration
>>> */
>>> - if (kvm_enabled()) {
>>> + //if (kvm_enabled()) {
>>> + if (0) {
>>> uint32_t ebx = 0, ecx = 0, edx = 0;
>>> host_cpuid(0, 0, NULL, &ebx, &ecx, &edx);
>>> x86_cpu_vendor_words2str(x86_cpu_def->vendor, ebx, edx,
>>> ecx);
>>>
>>> And the information of CPU remains consistent and the VM runs OK, even
>>> though with nested environment.
>>>
>>> Why should qemu set simulated cpu's vendor same as the host in KVM
>>> environment?
>>
>> The reason (and a way out) is given in the comment above the cited code.
>>
>> Jan
>>
>>
>
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Jan Kiszka <jan.kiszka@web.de>
To: "\"李春奇 <Arthur Chunqi Li>\"" <yzt356@gmail.com>
Cc: qemu-devel@nongnu.org, kvm <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] CPU vendor in KVM
Date: Sat, 04 May 2013 10:47:09 +0200 [thread overview]
Message-ID: <5184CB0D.4010004@web.de> (raw)
In-Reply-To: <CABpY8M+ZjO4xKWdV-6F5QJok1qJTd+iW6Q1LPi_3tNUa0=X4Rg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1889 bytes --]
Please don't top-post.
On 2013-05-04 10:45, 李春奇 <Arthur Chunqi Li> wrote:
> But will the difference between the vendor ID and family number cause
> confusion to the OS in VM?
The confusion is not yet clear to me. About which "-cpu ..." were you
talking?
Jan
>
> On Sat, May 4, 2013 at 4:05 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
>> On 2013-05-04 09:50, 李春奇 <Arthur Chunqi Li> wrote:
>>> Hi Jan and All,
>>> I find that when enable KVM with qemu, vendor ID of simulated CPU will be
>>> set the same as host, but other features such as level, family, model,
>>> stepping are not changed. This may bring out a confusing result, the
>>> simulated CPU has a vendor name of "GenuineIntel" but with family number
>>> "16".
>>>
>>> I disabled the related code in function cpu_x86_find_by_name:
>>> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
>>> index e2302d8..df0e82e 100644
>>> --- a/target-i386/cpu.c
>>> +++ b/target-i386/cpu.c
>>> @@ -1295,7 +1295,8 @@ static int cpu_x86_find_by_name(x86_def_t
>>> *x86_cpu_def, const char *name)
>>> * KVM's sysenter/syscall emulation in compatibility mode and
>>> * when doing cross vendor migration
>>> */
>>> - if (kvm_enabled()) {
>>> + //if (kvm_enabled()) {
>>> + if (0) {
>>> uint32_t ebx = 0, ecx = 0, edx = 0;
>>> host_cpuid(0, 0, NULL, &ebx, &ecx, &edx);
>>> x86_cpu_vendor_words2str(x86_cpu_def->vendor, ebx, edx,
>>> ecx);
>>>
>>> And the information of CPU remains consistent and the VM runs OK, even
>>> though with nested environment.
>>>
>>> Why should qemu set simulated cpu's vendor same as the host in KVM
>>> environment?
>>
>> The reason (and a way out) is given in the comment above the cited code.
>>
>> Jan
>>
>>
>
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2013-05-04 8:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-04 7:50 CPU vendor in KVM 李春奇 <Arthur Chunqi Li>
2013-05-04 7:50 ` [Qemu-devel] " 李春奇 <Arthur Chunqi Li>
2013-05-04 8:05 ` Jan Kiszka
2013-05-04 8:05 ` [Qemu-devel] " Jan Kiszka
2013-05-04 8:45 ` 李春奇 <Arthur Chunqi Li>
2013-05-04 8:45 ` [Qemu-devel] " 李春奇 <Arthur Chunqi Li>
2013-05-04 8:47 ` Jan Kiszka [this message]
2013-05-04 8:47 ` Jan Kiszka
2013-05-04 8:52 ` 李春奇 <Arthur Chunqi Li>
2013-05-04 8:52 ` [Qemu-devel] " 李春奇 <Arthur Chunqi Li>
2013-05-04 9:01 ` Jan Kiszka
2013-05-04 9:01 ` [Qemu-devel] " Jan Kiszka
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=5184CB0D.4010004@web.de \
--to=jan.kiszka@web.de \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=yzt356@gmail.com \
/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.