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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 24 Jan 2018, Andrew Cooper wrote:
> On 24/01/18 00:47, Stefano Stabellini 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?
> 
> This is quite unpleasant.
> 
> What is your usecase here? The assertion hit demonstrates Qemu doesn't
> function reasonably for a core piece of x86 architecture.  Given the
> fact that the calculation yeilds 0, I expect a guest can probably
> (ab)use this to escalate privilege.

My use case is test automation: testing Xen changes and verifying that
Xen boots. But I'll follow up on the QEMU side of things as well to fix
the issue.

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