Message ID | BANLkTimzTSU7A-b9yc9H35b1szfL4z7H-A@mail.gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On 05/10/2011 11:02 AM, BrillyWu wrote: > From: BrillyWu<brillywu@viatech.com.cn> > > When KVM is running on VIA CPU with host cpu's model, the > feautures of VIA CPU will be passed into kvm guest by calling > the CPUID instruction for Centaur. > Applied, thanks.
On 2011-05-10 10:02, BrillyWu wrote: > From: BrillyWu <brillywu@viatech.com.cn> > > When KVM is running on VIA CPU with host cpu's model, the > feautures of VIA CPU will be passed into kvm guest by calling > the CPUID instruction for Centaur. > > Signed-off-by: BrillyWu<brillywu@viatech.com.cn> > Signed-off-by: KaryJin<karyjin@viatech.com.cn> > --- > target-i386/cpu.h | 3 +++ > target-i386/cpuid.c | 46 +++++++++++++++++++++++++++++++++++++++++++++- > target-i386/kvm.c | 15 +++++++++++++++ > 3 files changed, 63 insertions(+), 1 deletion(-) > > --- a/target-i386/cpu.h 2011-05-09 09:55:48.624885001 +0800 > +++ b/target-i386/cpu.h 2011-05-09 09:48:53.704885019 +0800 > @@ -721,6 +721,9 @@ typedef struct CPUX86State { > uint32_t cpuid_ext3_features; > uint32_t cpuid_apic_id; > int cpuid_vendor_override; > + /* Store the results of Centaur's CPUID instructions */ > + uint32_t cpuid_xlevel2; > + uint32_t cpuid_ext4_features; > > /* MTRRs */ > uint64_t mtrr_fixed[11]; > --- a/target-i386/cpuid.c 2011-05-09 09:31:11.754884991 +0800 > +++ b/target-i386/cpuid.c 2011-05-09 10:18:46.204885008 +0800 > @@ -230,6 +230,9 @@ typedef struct x86_def_t { > char model_id[48]; > int vendor_override; > uint32_t flags; > + /* Store the results of Centaur's CPUID instructions */ > + uint32_t ext4_features; > + uint32_t xlevel2; > } x86_def_t; > > #define I486_FEATURES (CPUID_FP87 | CPUID_VME | CPUID_PSE) > @@ -522,6 +525,18 @@ static int cpu_x86_fill_host(x86_def_t * > cpu_x86_fill_model_id(x86_cpu_def->model_id); > x86_cpu_def->vendor_override = 0; > > + /* Call Centaur's CPUID instruction. */ > + if (x86_cpu_def->vendor1 == CPUID_VENDOR_VIA_1 && > + x86_cpu_def->vendor2 == CPUID_VENDOR_VIA_2 && > + x86_cpu_def->vendor3 == CPUID_VENDOR_VIA_3) { CPUID_VENDOR_VIA_* definitions in target-i386/cpu.h are missing so that this patch breaks current uq/master build. Please fix. Thanks, Jan
On 2011-05-10 10:02, BrillyWu wrote: > From: BrillyWu <brillywu@viatech.com.cn> > > When KVM is running on VIA CPU with host cpu's model, the > feautures of VIA CPU will be passed into kvm guest by calling > the CPUID instruction for Centaur. > > Signed-off-by: BrillyWu<brillywu@viatech.com.cn> > Signed-off-by: KaryJin<karyjin@viatech.com.cn> ... > @@ -855,6 +870,8 @@ int cpu_x86_register (CPUX86State *env, > env->cpuid_xlevel = def->xlevel; > env->cpuid_kvm_features = def->kvm_features; > env->cpuid_svm_features = def->svm_features; > + env->cpuid_ext4_features = def->ext4_features; > + env->cpuid_xlevel2 = def->xlevel2; > if (!kvm_enabled()) { > env->cpuid_features &= TCG_FEATURES; > env->cpuid_ext_features &= TCG_EXT_FEATURES; > @@ -1034,7 +1051,12 @@ void cpu_x86_cpuid(CPUX86State *env, uin > uint32_t *ecx, uint32_t *edx) > { > /* test if maximum index reached */ > - if (index & 0x80000000) { > + if ((index & 0xC000000f) == index) { This condition can't be correct. It triggers on every index <= 15 and breaks qemu. > + /* Handle the Centaur's CPUID instruction. */ > + if (index > env->cpuid_xlevel2) { > + index = env->cpuid_xlevel2; > + } > + } else if (index & 0x80000000) { Your very first version looked like this: - if (index & 0x80000000) { + if ((index & 0xC0000000) == 0xC0000000) { + /* Handle the Centaur's CPUID instruction.* + * If cpuid_xlevel2 is "0", then put into the* + * default case. */ + if (env->cpuid_xlevel2 == 0) + index = 0xF0000000; + else if (index > env->cpuid_xlevel2) + index = env->cpuid_xlevel2; + } else if (index & 0x80000000) { Something went wrong here, please re-validate the patch carefully. Jan
Hi, Jan > > > @@ -855,6 +870,8 @@ int cpu_x86_register (CPUX86State *env, > > env->cpuid_xlevel = def->xlevel; > > env->cpuid_kvm_features = def->kvm_features; > > env->cpuid_svm_features = def->svm_features; > > + env->cpuid_ext4_features = def->ext4_features; > > + env->cpuid_xlevel2 = def->xlevel2; > > if (!kvm_enabled()) { > > env->cpuid_features &= TCG_FEATURES; > > env->cpuid_ext_features &= TCG_EXT_FEATURES; @@ -1034,7 > > +1051,12 @@ void cpu_x86_cpuid(CPUX86State *env, uin > > uint32_t *ecx, uint32_t *edx) { > > /* test if maximum index reached */ > > - if (index & 0x80000000) { > > + if ((index & 0xC000000f) == index) { > > This condition can't be correct. It triggers on every index <= 15 and > breaks qemu. I'm so sorry to make such a stupid mistake. Thank you very for your revieview. > > > + /* Handle the Centaur's CPUID instruction. */ > > + if (index > env->cpuid_xlevel2) { > > + index = env->cpuid_xlevel2; > > + } > > + } else if (index & 0x80000000) { > > Your very first version looked like this: The first version has some problem, so you could ignore it. > > - if (index & 0x80000000) { > + if ((index & 0xC0000000) == 0xC0000000) { > + /* Handle the Centaur's CPUID instruction.* > + * If cpuid_xlevel2 is "0", then put into the* > + * default case. */ > + if (env->cpuid_xlevel2 == 0) > + index = 0xF0000000; > + else if (index > env->cpuid_xlevel2) > + index = env->cpuid_xlevel2; > + } else if (index & 0x80000000) { > > Something went wrong here, please re-validate the patch carefully. Ok, I will check it soon. -- 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
On 2011-05-30 09:40, BrillyWu wrote: > From: BrillyWu <brillywu@viatech.com.cn> > > Hi, Jan > I'm very sorry for these bugs in the patch. Now I have made a > new patch based on the > newest uq/master where the patch has been applied to fix these bugs, > is it feasible? If it is > not acceptable, should I re-generate a patch based on previous > uq/master, or what else? A clean patch (which passed checkpatch...) against uq/master without the broken version is required. We can't push a non-bisectable series upstream. Jan
On 2011-05-30 10:59, BrillyWu wrote: > From BrillyWu@viatech.com.cn > Hi, Jan > Thank you for you review and guide. > I have fixed the bugs and re-generated a clean patch which has > been checked. It can be compiled > without any error and work normally. > The patch v3 is here now. The above text can't be used as a commit log, so this needs to be fixed. Moreover, your patch still contains at least on style issues scripts/checkpatch.pl should have caught. Are you sure you ran it? Jan
Hi, Jan > patch which has > > been checked. It can be compiled without any error and work > normally. > > The patch v3 is here now. > > The above text can't be used as a commit log, so this needs to be > fixed. > Moreover, your patch still contains at least on style issues > scripts/checkpatch.pl should have caught. Are you sure you ran it? > I am sure I have checked it with the scripts/checkpatch.pl, and it shows no error or warning. Maybe I should check whether my windows editor and mail client can work well before sending it to you. I 'm sorry. OK, I will use the previous commit log, and send it to you in the new thread. -- 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
On 2011-05-31 03:25, BrillyWu wrote: > Hi, Jan > >> patch which has >>> been checked. It can be compiled without any error and work >> normally. >>> The patch v3 is here now. >> >> The above text can't be used as a commit log, so this needs to be >> fixed. >> Moreover, your patch still contains at least on style issues >> scripts/checkpatch.pl should have caught. Are you sure you ran it? >> > > I am sure I have checked it with the scripts/checkpatch.pl, and it > shows no error or warning. Maybe I should check whether my windows > editor and mail client can work well before sending it to you. I 'm > sorry. Sorry, you are right. Your patch revealed a bug in the checkpatch script. Blue, this does not trigger the missing braces warning: @@ -1035,8 +1052,17 @@ void cpu_x86_cpuid(CPUX86State *env, uin { /* test if maximum index reached */ if (index & 0x80000000) { - if (index > env->cpuid_xlevel) - index = env->cpuid_level; + if (index > env->cpuid_xlevel) { + if (env->cpuid_xlevel2 > 0) { + /* Handle the Centaur's CPUID instruction. */ + if (index > env->cpuid_xlevel2) { + index = env->cpuid_xlevel2; + } else if (index < 0xC0000000) { + index = env->cpuid_xlevel; + } + } else + index = env->cpuid_xlevel; + } } else { if (index > env->cpuid_level) index = env->cpuid_level; > OK, I will use the previous commit log, and send it to you in the new thread. Thanks. I think it would be fair to fix up the braces on commit now. Jan
Hi, Jan > > I am sure I have checked it with the scripts/checkpatch.pl, and it > > shows no error or warning. Maybe I should check whether my windows > > editor and mail client can work well before sending it to > you. I 'm > > sorry. > > Sorry, you are right. Your patch revealed a bug in the checkpatch > script. > > Blue, this does not trigger the missing braces warning: Do you mean the bug is that it can not trigger missing braces warining? It seems that there is no missing braces in my patch, but some unnecessary braces. > > @@ -1035,8 +1052,17 @@ void cpu_x86_cpuid(CPUX86State *env, uin { > /* test if maximum index reached */ > if (index & 0x80000000) { > - if (index > env->cpuid_xlevel) > - index = env->cpuid_level; > + if (index > env->cpuid_xlevel) { > + if (env->cpuid_xlevel2 > 0) { > + /* Handle the Centaur's CPUID instruction. */ > + if (index > env->cpuid_xlevel2) { > + index = env->cpuid_xlevel2; > + } else if (index < 0xC0000000) { > + index = env->cpuid_xlevel; > + } > + } else > + index = env->cpuid_xlevel; > + } > } else { > if (index > env->cpuid_level) > index = env->cpuid_level; > > > > OK, I will use the previous commit log, and send it to you > in the new thread. > > Thanks. I think it would be fair to fix up the braces on commit now. It looks that there are some unnecessary braces, but if I remove them, the script/checkpatch.pl will report warnings. Could I ignore it? BTW, I have submited a patch v3 a few minutes before withou fixing up the braces, and I have tested it with my mail client this time, so it could be OK now. -- 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
On 2011-05-31 09:39, BrillyWu wrote: > Hi, Jan > >>> I am sure I have checked it with the scripts/checkpatch.pl, and it >>> shows no error or warning. Maybe I should check whether my windows >>> editor and mail client can work well before sending it to >> you. I 'm >>> sorry. >> >> Sorry, you are right. Your patch revealed a bug in the checkpatch >> script. >> >> Blue, this does not trigger the missing braces warning: > > Do you mean the bug is that it can not trigger missing braces warining? The script fails to detect missing braces as marked below. > It seems that there is no missing braces in my patch, but some > unnecessary braces. There are no unnecessary braces according to QEMU coding style. > >> >> @@ -1035,8 +1052,17 @@ void cpu_x86_cpuid(CPUX86State *env, uin { >> /* test if maximum index reached */ >> if (index & 0x80000000) { >> - if (index > env->cpuid_xlevel) >> - index = env->cpuid_level; >> + if (index > env->cpuid_xlevel) { >> + if (env->cpuid_xlevel2 > 0) { >> + /* Handle the Centaur's CPUID instruction. */ >> + if (index > env->cpuid_xlevel2) { >> + index = env->cpuid_xlevel2; >> + } else if (index < 0xC0000000) { >> + index = env->cpuid_xlevel; >> + } >> + } else >> + index = env->cpuid_xlevel; This should be: } else { index = ... } >> + } >> } else { >> if (index > env->cpuid_level) >> index = env->cpuid_level; >> >> >>> OK, I will use the previous commit log, and send it to you >> in the new thread. >> >> Thanks. I think it would be fair to fix up the braces on commit now. > > It looks that there are some unnecessary braces, but if I remove them, > the script/checkpatch.pl will report warnings. Could I ignore it? Nope, see above. > BTW, I have submited a patch v3 a few minutes before withou fixing up > the braces, and I have tested it with my mail client this time, so it > could be OK now. Yes, your mail client works fine as far as I can see. Jan
> >> Blue, this does not trigger the missing braces warning: > > > > Do you mean the bug is that it can not trigger missing > braces warining? > > The script fails to detect missing braces as marked below. > > > It seems that there is no missing braces in my patch, but some > > unnecessary braces. > > There are no unnecessary braces according to QEMU coding style. Oh, I see. Thank you! > >> + index = env->cpuid_xlevel; > >> + } > >> + } else > >> + index = env->cpuid_xlevel; > > This should be: > > } else { > index = ... > } > > >> + } > > Nope, see above. It looks that I should add the missing braces. > > > BTW, I have submited a patch v3 a few minutes before withou > fixing up > > the braces, and I have tested it with my mail client this > time, so it > > could be OK now. > > Yes, your mail client works fine as far as I can see. Yes, you are right. It seems to be the problem of my editor. I'll check whether other places need any brace, and then send it to the patch v3 thread. -- 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
--- a/target-i386/cpu.h 2011-05-09 09:55:48.624885001 +0800 +++ b/target-i386/cpu.h 2011-05-09 09:48:53.704885019 +0800 @@ -721,6 +721,9 @@ typedef struct CPUX86State { uint32_t cpuid_ext3_features; uint32_t cpuid_apic_id; int cpuid_vendor_override; + /* Store the results of Centaur's CPUID instructions */ + uint32_t cpuid_xlevel2; + uint32_t cpuid_ext4_features; /* MTRRs */ uint64_t mtrr_fixed[11]; --- a/target-i386/cpuid.c 2011-05-09 09:31:11.754884991 +0800 +++ b/target-i386/cpuid.c 2011-05-09 10:18:46.204885008 +0800 @@ -230,6 +230,9 @@ typedef struct x86_def_t { char model_id[48]; int vendor_override; uint32_t flags; + /* Store the results of Centaur's CPUID instructions */ + uint32_t ext4_features; + uint32_t xlevel2; } x86_def_t; #define I486_FEATURES (CPUID_FP87 | CPUID_VME | CPUID_PSE) @@ -522,6 +525,18 @@ static int cpu_x86_fill_host(x86_def_t * cpu_x86_fill_model_id(x86_cpu_def->model_id); x86_cpu_def->vendor_override = 0; + /* Call Centaur's CPUID instruction. */ + if (x86_cpu_def->vendor1 == CPUID_VENDOR_VIA_1 && + x86_cpu_def->vendor2 == CPUID_VENDOR_VIA_2 && + x86_cpu_def->vendor3 == CPUID_VENDOR_VIA_3) { + host_cpuid(0xC0000000, 0, &eax, &ebx, &ecx, &edx); + if (eax >= 0xC0000001) { + /* Support VIA max extended level */ + x86_cpu_def->xlevel2 = eax; + host_cpuid(0xC0000001, 0, &eax, &ebx, &ecx, &edx); + x86_cpu_def->ext4_features = edx; + } + } /* * Every SVM feature requires emulation support in KVM - so we can't just @@ -855,6 +870,8 @@ int cpu_x86_register (CPUX86State *env, env->cpuid_xlevel = def->xlevel; env->cpuid_kvm_features = def->kvm_features; env->cpuid_svm_features = def->svm_features; + env->cpuid_ext4_features = def->ext4_features; + env->cpuid_xlevel2 = def->xlevel2; if (!kvm_enabled()) { env->cpuid_features &= TCG_FEATURES; env->cpuid_ext_features &= TCG_EXT_FEATURES; @@ -1034,7 +1051,12 @@ void cpu_x86_cpuid(CPUX86State *env, uin uint32_t *ecx, uint32_t *edx) { /* test if maximum index reached */ - if (index & 0x80000000) { + if ((index & 0xC000000f) == index) { + /* Handle the Centaur's CPUID instruction. */ + if (index > env->cpuid_xlevel2) { + index = env->cpuid_xlevel2; + } + } else if (index & 0x80000000) { if (index > env->cpuid_xlevel) index = env->cpuid_level; } else { @@ -1256,6 +1278,28 @@ void cpu_x86_cpuid(CPUX86State *env, uin *edx = 0; } break; + case 0xC0000000: + *eax = env->cpuid_xlevel2; + *ebx = 0; + *ecx = 0; + *edx = 0; + break; + case 0xC0000001: + /* Support for VIA CPU's CPUID instruction */ + *eax = env->cpuid_version; + *ebx = 0; + *ecx = 0; + *edx = env->cpuid_ext4_features; + break; + case 0xC0000002: + case 0xC0000003: + case 0xC0000004: + /* Reserved for the future, and now filled with zero */ + *eax = 0; + *ebx = 0; + *ecx = 0; + *edx = 0; + break; default: /* reserved values: zero */ *eax = 0; --- a/target-i386/kvm.c 2011-05-09 09:31:04.284884996 +0800 +++ b/target-i386/kvm.c 2011-05-09 09:55:42.984885014 +0800 @@ -492,6 +492,21 @@ int kvm_arch_init_vcpu(CPUState *env) cpu_x86_cpuid(env, i, 0, &c->eax, &c->ebx, &c->ecx, &c->edx); } + /* Call Centaur's CPUID instructions they are supported. */ + if (env->cpuid_xlevel2 > 0) { + env->cpuid_ext4_features &= + kvm_arch_get_supported_cpuid(env, 0xC0000001, 0, R_EDX); + cpu_x86_cpuid(env, 0xC0000000, 0, &limit, &unused, &unused, &unused); + + for (i = 0xC0000000; i <= limit; i++) { + c = &cpuid_data.entries[cpuid_i++]; + + c->function = i; + c->flags = 0; + cpu_x86_cpuid(env, i, 0, &c->eax, &c->ebx, &c->ecx, &c->edx); + } + } + cpuid_data.cpuid.nent = cpuid_i; #ifdef KVM_CAP_MCE