[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.