Nitin A Kamble wrote:
Hi Avi,
Attached is a patch to handle the "host mode" as you mentioned earlier.
It works this way:
Qemu's -cpu option is extended to take a new paramenter: -cpu _host_.
With that parameter the cpuid bits are collected from the host cpu. And
few bits of cleared to get it working with the kvm.
I tested the patch with Windows & Linux guests, and I see the host
topology is propagating into the guest. With that windows server is not
imposing the incorrect licensing restriction to guest, as it was doing
earlier. With the patch I could bring up the windows server guest with
16 cpus on kvm.
I also fixed implementation of indexed cpuid leaves (0x4 & 0xb) in
qemu. And also some code cleanup are there for consistent terminology to
have more readable code,
Please check-in the patch in kvm-usermode.git tree. There are no
changes for the kernel side or kvm.git tree for this.
Signed-Off-By: Nitin A Kamble <[EMAIL PROTECTED]>
Next things:
* Default mode: I am not planning to do anything for this. I see the
current situation is good enough for the default mode.
* Managed mode: For this, I am thinking few things.
1. Either an option can be added to qemu to take (almost) all of
it's cpuid bits from a file.
2. Or use command line options to modify particular bits of guest
cpuid.
3. Or do the both.
What do you think about the managed mode implementation? you probably
have better idea regarding how and what kind of tools will be managing
it.
+static int fill_x86_defs_for_host(CPUX86State *env, x86_def_t * def)
+{
+ uint32 eax, ebx, ecx, edx;
+
+ env->cpu_host_cpu = 1;
+
+ host_cpuid(0, 0, &eax, &ebx, &ecx, &edx);
+ env->cpuid_level = eax;
+ env->cpuid_vendor1 = ebx;
+ env->cpuid_vendor2 = ecx;
+ env->cpuid_vendor3 = edx;
+
+ host_cpuid(1, 0, &eax, &ebx, &ecx, &edx);
+ env->cpuid_version = eax;
+ env->cpuid_features = edx & 0xdfffffff; /* disable Thermal Monitro */
+ env->cpuid_ext_features = ecx;
+
+ host_cpuid(0x80000000, 0, &eax, &ebx, &ecx, &edx);
+ env->cpuid_xlevel = eax;
+
+ host_cpuid(0x80000001, 0, &eax, &ebx, &ecx, &edx);
+ env->cpuid_ext3_features = ecx;
+ env->cpuid_ext2_features = edx & 0xf7ffffff; /* disable rdtscp */
+
+ host_cpuid(0x80000002, 0, &eax, &ebx, &ecx, &edx);
+ env->cpuid_model[0] = eax;
+ env->cpuid_model[1] = ebx;
+ env->cpuid_model[2] = ecx;
+ env->cpuid_model[3] = edx;
+
+ host_cpuid(0x80000003, 0, &eax, &ebx, &ecx, &edx);
+ env->cpuid_model[4] = eax;
+ env->cpuid_model[5] = ebx;
+ env->cpuid_model[6] = ecx;
+ env->cpuid_model[7] = edx;
+
+ host_cpuid(0x80000004, 0, &eax, &ebx, &ecx, &edx);
+ env->cpuid_model[8] = eax;
+ env->cpuid_model[9] = ebx;
+ env->cpuid_model[10] = ecx;
+ env->cpuid_model[11] = edx;
+
+ return 0;
+}
+
There is already a kernel function for this (KVM_GET_SUPPORTED_CPUID,
IIRC) that does this. It has the advantage of knowing which bits the
kernel supports, so there's no need to keep the kernel and userspace at
the same version.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
