From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33621) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VROF6-0005Bl-PV for qemu-devel@nongnu.org; Wed, 02 Oct 2013 11:21:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VROEz-0000xD-7U for qemu-devel@nongnu.org; Wed, 02 Oct 2013 11:21:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62880) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VROEy-0000wM-Vl for qemu-devel@nongnu.org; Wed, 02 Oct 2013 11:21:29 -0400 Date: Wed, 2 Oct 2013 18:21:26 +0300 From: Gleb Natapov Message-ID: <20131002152126.GM17294@redhat.com> References: <1379080558-16499-1-git-send-email-pbonzini@redhat.com> <1379080558-16499-3-git-send-email-pbonzini@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1379080558-16499-3-git-send-email-pbonzini@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 uq/master 2/2] x86: cpuid: reconstruct leaf 0Dh data List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On Fri, Sep 13, 2013 at 03:55:58PM +0200, Paolo Bonzini wrote: > The data in leaf 0Dh depends on information from other feature bits. > Instead of passing it blindly from the host, compute it based on > whether these feature bits are enabled. > > Signed-off-by: Paolo Bonzini > --- > target-i386/cpu.c | 63 +++++++++++++++++++++++++++++++++++++++------------- > 1 file changed, 47 insertions(+), 16 deletions(-) > > diff --git a/target-i386/cpu.c b/target-i386/cpu.c > index ac83106..e6179f4 100644 > --- a/target-i386/cpu.c > +++ b/target-i386/cpu.c > @@ -328,6 +328,15 @@ X86RegisterInfo32 x86_reg_info_32[CPU_NB_REGS32] = { > }; > #undef REGISTER > > +typedef struct ExtSaveArea { > + uint32_t feature, bits; > + uint32_t offset, size; > +} ExtSaveArea; > + > +static const ExtSaveArea ext_save_areas[] = { > + [2] = { .feature = FEAT_1_ECX, .bits = CPUID_EXT_AVX, > + .offset = 0x100, .size = 0x240 }, > +}; > > const char *get_register_name_32(unsigned int reg) > { > @@ -2169,29 +2178,51 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count, > *edx = 0; > } > break; > - case 0xD: > + case 0xD: { > + KVMState *s = cs->kvm_state; > + uint64_t kvm_mask; > + int i; > + > /* Processor Extended State */ > - if (!(env->features[FEAT_1_ECX] & CPUID_EXT_XSAVE)) { > - *eax = 0; > - *ebx = 0; > - *ecx = 0; > - *edx = 0; > + *eax = 0; > + *ebx = 0; > + *ecx = 0; > + *edx = 0; > + if (!(env->features[FEAT_1_ECX] & CPUID_EXT_XSAVE) || !kvm_enabled()) { > break; > } > - if (kvm_enabled()) { > - KVMState *s = cs->kvm_state; > + kvm_mask = > + kvm_arch_get_supported_cpuid(s, 0xd, 0, R_EAX) | > + ((uint64_t)kvm_arch_get_supported_cpuid(s, 0xd, 0, R_EDX) << 32); > > - *eax = kvm_arch_get_supported_cpuid(s, 0xd, count, R_EAX); > - *ebx = kvm_arch_get_supported_cpuid(s, 0xd, count, R_EBX); > - *ecx = kvm_arch_get_supported_cpuid(s, 0xd, count, R_ECX); > - *edx = kvm_arch_get_supported_cpuid(s, 0xd, count, R_EDX); > - } else { > - *eax = 0; > - *ebx = 0; > - *ecx = 0; > - *edx = 0; > + if (count == 0) { > + *ecx = 0x240; > + for (i = 2; i < ARRAY_SIZE(ext_save_areas); i++) { > + const ExtSaveArea *esa = &ext_save_areas[i]; > + if ((env->features[esa->feature] & esa->bits) == esa->bits && > + (kvm_mask & (1 << i)) != 0) { > + if (i < 32) { > + *eax |= 1 << i; > + } else { > + *edx |= 1 << (i - 32); > + } > + *ecx = MAX(*ecx, esa->offset + esa->size); > + } > + } > + *eax |= kvm_mask & 3; Lets use define from previous patch. > + *ebx = *ecx; > + } else if (count == 1) { > + *eax = kvm_arch_get_supported_cpuid(s, 0xd, 1, R_EAX); > + } else if (count < ARRAY_SIZE(ext_save_areas)) { > + const ExtSaveArea *esa = &ext_save_areas[count]; > + if ((env->features[esa->feature] & esa->bits) == esa->bits && > + (kvm_mask & (1 << count)) != 0) { > + *eax = esa->offset; > + *ebx = esa->size; Why do you hard code them instead of querying kernel? What if they depend on cpu type? (well if this happens we can forget about migration, but still...) > + } > } > break; > + } > case 0x80000000: > *eax = env->cpuid_xlevel; > *ebx = env->cpuid_vendor1; > -- > 1.8.3.1 > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb.