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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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.

Thanks, Roger.

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