[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen fails to boot inside QEMU on x86, no VMX:
>>> On 24.01.18 at 01:47, <sstabellini@xxxxxxxxxx> wrote: > On Tue, 23 Jan 2018, Jan Beulich wrote: >> >>> On 23.01.18 at 01:41, <andrew.cooper3@xxxxxxxxxx> wrote: >> > On 23/01/2018 00:38, Stefano Stabellini wrote: >> >> On Tue, 23 Jan 2018, Andrew Cooper wrote: >> >>> On 22/01/2018 23:48, Stefano Stabellini wrote: >> >>>> Hi all, >> >>>> >> >>>> Running Xen inside QEMU x86 without KVM acceleartion and without VMX >> >>>> emulation leads to the failure appended below. >> >>>> >> >>>> This trivial workaround "fixes" the problem: >> >>>> >> >>>> diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c >> >>>> index 72f30d9..a67d6c1 100644 >> >>>> --- a/xen/arch/x86/extable.c >> >>>> +++ b/xen/arch/x86/extable.c >> >>>> @@ -168,7 +168,6 @@ static int __init stub_selftest(void) >> >>>> _ASM_EXTABLE(.Lret%=, .Lfix%=) >> >>>> : [exn] "+m" (res) >> >>>> : [stb] "r" (addr), "a" (tests[i].rax)); >> >>>> - ASSERT(res == tests[i].res.raw); >> >>>> } >> >>>> >> >>>> return 0; >> >>>> >> >>>> >> >>>> Any suggestions? >> >>> Which i failed? This will probably be an emulation bug in Qemu. >> >> i=2 is the culprit >> > >> > Qemu doesn't emulate %rsp-based memory accesses properly. It should >> > raise #SS[0], and is presumably raising #GP[0] instead. >> >> Right, the value on %rax supports that suspicion. Dropping the >> ASSERT() is no option, of course. If we were able to reliably >> detect that we're running under qemu, we could cater for this >> special case, but I can't seem to be able to think of other options >> besides adding a command line option allowing to bypass the self >> test. > > I am going to give a look at the QEMU side of things. However, even if I > fix the bug in QEMU, it won't solve the problem for all the QEMU > instances already out there, shipped by distros, etc. > > So, I think that regardless of the QEMU fix, we also need to add a > workaround in Xen. We can detect QEMU from the cpuid string, which is > going to be TCGTCGTCGTCG. > > What do you think of something like below? Well, not really nice, but what do you do. In a cleaned up form this may well be acceptable. Jan > diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c > index 6cf3628..471e394 100644 > --- a/xen/arch/x86/cpu/common.c > +++ b/xen/arch/x86/cpu/common.c > @@ -280,6 +280,21 @@ static void __init early_cpu_detect(void) > initialize_cpu_data(0); > } > > +bool tcg_workaround = false; > +static inline void hypervisor_cpuid_base(struct cpuinfo_x86 *c) > +{ > + uint32_t base, eax, signature[3]; > + char *sig = "TCGTCGTCGTCG"; > + > + if ( c->phys_proc_id ) > + return; > + > + base = 0x40000000; > + cpuid(base, &eax, &signature[0], &signature[1], &signature[2]); > + if ( !memcmp(sig, signature, 12) ) > + tcg_workaround = true; > +} > + > static void generic_identify(struct cpuinfo_x86 *c) > { > u32 eax, ebx, ecx, edx, tmp; > @@ -343,6 +358,8 @@ static void generic_identify(struct cpuinfo_x86 *c) > > &c->x86_capability[cpufeat_word(X86_FEATURE_FSGSBASE)], > &c->x86_capability[cpufeat_word(X86_FEATURE_PKU)], > > &c->x86_capability[cpufeat_word(X86_FEATURE_AVX512_4VNNIW)]); > + > + hypervisor_cpuid_base(c); > } > > /* > diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c > index 6fffe05..6c8ca3d 100644 > --- a/xen/arch/x86/extable.c > +++ b/xen/arch/x86/extable.c > @@ -146,6 +146,9 @@ static int __init stub_selftest(void) > unsigned long addr = this_cpu(stubs.addr) + STUB_BUF_SIZE / 2; > unsigned int i; > > + if ( tcg_workaround ) > + return 0; > + > printk("Running stub recovery selftests...\n"); > > for ( i = 0; i < ARRAY_SIZE(tests); ++i ) > diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h > index 41a8d8c..dfc4537 100644 > --- a/xen/include/asm-x86/processor.h > +++ b/xen/include/asm-x86/processor.h > @@ -556,6 +556,7 @@ int early_microcode_update_cpu(bool start_update); > int early_microcode_init(void); > int microcode_init_intel(void); > int microcode_init_amd(void); > +extern bool tcg_workaround; > > enum get_cpu_vendor { > gcv_host, _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |