[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen fails to boot inside QEMU on x86, no VMX:
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |