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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 24 Jan 2018, Roger Pau Monné wrote:
> On Tue, Jan 23, 2018 at 04:47:51PM -0800, 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?
> 
> The shim code added a probe_hypervisor call into __start_xen, do you
> think you could hook this test there?
> 
> It might make sense to have something like:
> 
> enum guest_type {
>     NONE,
>     XEN,
>     QEMU,
> };
> enum guest_type guest;
> 
> As a global variable that would replace xen_guest.

I could hook the test there, but then the QEMU workaround would be tied
to CONFIG_XEN_GUEST, when actually it doesn't have anything to do with
it.

Unless you are also suggesting to move probe_hypervisor out of
xen/arch/x86/guest?

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