Re: [Xen-devel] Xen fails to boot inside QEMU on x86, no VMX

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel