* [Qemu-devel] CPU vendor in KVM
@ 2013-05-04 7:50 李春奇 <Arthur Chunqi Li>
2013-05-04 8:05 ` Jan Kiszka
0 siblings, 1 reply; 6+ messages in thread
From: 李春奇 <Arthur Chunqi Li> @ 2013-05-04 7:50 UTC (permalink / raw)
To: qemu-devel, kvm; +Cc: Jan Kiszka
[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]
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?
--
Arthur Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China
[-- Attachment #2: Type: text/html, Size: 1693 bytes --]
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] CPU vendor in KVM
2013-05-04 7:50 [Qemu-devel] CPU vendor in KVM 李春奇 <Arthur Chunqi Li>
@ 2013-05-04 8:05 ` Jan Kiszka
2013-05-04 8:45 ` 李春奇 <Arthur Chunqi Li>
0 siblings, 1 reply; 6+ messages in thread
From: Jan Kiszka @ 2013-05-04 8:05 UTC (permalink / raw)
To: "李春奇 <Arthur Chunqi Li>"
Cc: qemu-devel, kvm
[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]
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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] CPU vendor in KVM
2013-05-04 8:05 ` Jan Kiszka
@ 2013-05-04 8:45 ` 李春奇 <Arthur Chunqi Li>
2013-05-04 8:47 ` Jan Kiszka
0 siblings, 1 reply; 6+ messages in thread
From: 李春奇 <Arthur Chunqi Li> @ 2013-05-04 8:45 UTC (permalink / raw)
To: Jan Kiszka; +Cc: qemu-devel, kvm
But will the difference between the vendor ID and family number cause
confusion to the OS in VM?
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
>
>
--
Arthur Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] CPU vendor in KVM
2013-05-04 8:45 ` 李春奇 <Arthur Chunqi Li>
@ 2013-05-04 8:47 ` Jan Kiszka
2013-05-04 8:52 ` 李春奇 <Arthur Chunqi Li>
0 siblings, 1 reply; 6+ messages in thread
From: Jan Kiszka @ 2013-05-04 8:47 UTC (permalink / raw)
To: "李春奇 <Arthur Chunqi Li>"
Cc: qemu-devel, kvm
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] CPU vendor in KVM
2013-05-04 8:47 ` Jan Kiszka
@ 2013-05-04 8:52 ` 李春奇 <Arthur Chunqi Li>
2013-05-04 9:01 ` Jan Kiszka
0 siblings, 1 reply; 6+ messages in thread
From: 李春奇 <Arthur Chunqi Li> @ 2013-05-04 8:52 UTC (permalink / raw)
To: Jan Kiszka; +Cc: qemu-devel, kvm
On Sat, May 4, 2013 at 4:47 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
> 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
>>>
>>>
>>
>>
>>
>
>
I use -cpu Opteron_G1, and got the following message in VM:
root@kvm1:~# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : AMD Opteron 240 (Gen 1 Class Opteron)
stepping : 1
microcode : 0x1
cpu MHz : 2393.998
cache size : 4096 KB
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush mmx fxsr sse sse2 syscall nx lm constant_tsc nopl pni
hypervisor
bogomips : 4787.99
clflush size : 64
cache_alignment : 128
address sizes : 40 bits physical, 48 bits virtual
power management:
The vendor_id is not consistent to the following messages.
Thanks,
Arthur
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] CPU vendor in KVM
2013-05-04 8:52 ` 李春奇 <Arthur Chunqi Li>
@ 2013-05-04 9:01 ` Jan Kiszka
0 siblings, 0 replies; 6+ messages in thread
From: Jan Kiszka @ 2013-05-04 9:01 UTC (permalink / raw)
To: "李春奇 <Arthur Chunqi Li>"
Cc: qemu-devel, kvm
[-- Attachment #1: Type: text/plain, Size: 3131 bytes --]
On 2013-05-04 10:52, 李春奇 <Arthur Chunqi Li> wrote:
> On Sat, May 4, 2013 at 4:47 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
>> 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
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
> I use -cpu Opteron_G1, and got the following message in VM:
> root@kvm1:~# cat /proc/cpuinfo
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 15
> model : 6
> model name : AMD Opteron 240 (Gen 1 Class Opteron)
> stepping : 1
> microcode : 0x1
> cpu MHz : 2393.998
> cache size : 4096 KB
> fpu : yes
> fpu_exception : yes
> cpuid level : 5
> wp : yes
> flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
> pse36 clflush mmx fxsr sse sse2 syscall nx lm constant_tsc nopl pni
> hypervisor
> bogomips : 4787.99
> clflush size : 64
> cache_alignment : 128
> address sizes : 40 bits physical, 48 bits virtual
> power management:
>
> The vendor_id is not consistent to the following messages.
The reason is what the comment says: Avoid that the guest picks a
suboptimal syscall mechanism that may have to be emulated by KVM all the
time. Obviously, this causes no problems with common guests as it is
done like this since day #1.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-05-04 9:02 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-05-04 7:50 [Qemu-devel] CPU vendor in KVM 李春奇 <Arthur Chunqi Li>
2013-05-04 8:05 ` Jan Kiszka
2013-05-04 8:45 ` 李春奇 <Arthur Chunqi Li>
2013-05-04 8:47 ` Jan Kiszka
2013-05-04 8:52 ` 李春奇 <Arthur Chunqi Li>
2013-05-04 9:01 ` Jan Kiszka
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).