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

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

On Wed, Jan 24, 2018 at 09:46:06AM -0800, Stefano Stabellini wrote:
> 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?

Yes, it should be moved somewhere else if also used by other
hypervisor detection, but given the nature of your issue I would
rather treat this as a CPU errata rather than a 'guest type'.

Treating QEMU as a guest type just for this seems overkill.

Thanks, Roger.

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