Xen project Mailing List

Re: [Xen-devel] XenDom0/FreeBSD: guest crash when nested virtualization is used

To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Oleg Ginzburg <olevole@xxxxxxxxxx>

Date: Thu, 25 Jul 2019 09:54:46 +0000

Accept-language: en-US

Arc-authentication-results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=suse.com;dmarc=pass action=none header.from=suse.com;dkim=pass header.d=suse.com;arc=none

Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yZqzdBsl16VW74NT8yKuV5dr5MhiXpZy0rZPZoD19RI=; b=MK2mLBAkL4Jc46XVIRmiv5HBritL8H3utDu1N2TC5t9G0c6qrb/tX63LjzpBZvJ0FomWzbQWJdECwU8gY1BV3Eumevf0nlVo0SfLVoeA5zEKoRd574gLRiLaytAGz1TjkMzZwfJsuBCMK1NUiGbwMhFohcp4HyeG0di8y54HM26ZSMNjyFGiKBZzjlga9rbv9Ud+YGq8sJqhYu0XDQMvlmhxEvbF1051q0UsGQWcwJFK0vvm1NUzBrBnYA7B17REJ8CD8nvj5RfkFfbPzimwLZHJfj8IUqbPu/nOTqeL2VkM4MX/xIFjm63UvpahlEusLo2sKKRUjkBlNzOo7X+f+g==

Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Em+ffwxPeyRCVKo0GL0r7KdF8hACDBZI3EDe1ZAz+VzqH5IkXUa6GxpPgprxtYLxGsJloHlxxBuCdwO2F6DNI6FlVoqmiIuBzZFONma+e+10XNtj+YsFB9lqS2RnPXKAe5VvNbMcPBCgZvwllujLR42Vd8duqTkd9AE82vgf4VG1ypQm0jVwoc7y9k7rG1+X57QZGFIkUWWHPPr9WublkD5gEv3RkoIJNzt9+bC24ZS1muKtRxGSd75XX5ZpXxsPDDL0rTFJR0uga1iXkRhR5hRVI3Wn5csv1Zf26oFLsACrluMKUJfekDoAPcucWfmADtjCn4OxDM2rpga0wHzT2g==

Authentication-results: spf=none (sender IP is ) smtp.mailfrom=JBeulich@xxxxxxxx;

Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>

Delivery-date: Thu, 25 Jul 2019 10:08:47 +0000

List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Thread-index: AQHVQkpB744ezSIHTEKNpVRjiIbStKbaFLrrgAEEpoA=

Thread-topic: [Xen-devel] XenDom0/FreeBSD: guest crash when nested virtualization is used

On 24.07.2019 20:19, Andrew Cooper wrote: > On 24/07/2019 19:02, Oleg Ginzburg wrote: >> (d2) Booting from Hard Disk... >> (d2) Booting from 0000:7c00 >> (XEN) d2v0 VMLAUNCH error: 0x7 So this tells us it's the very first insn in the (nested) guest that causes the failure. >> (XEN) *** Guest State *** >> (XEN) CR0: actual=0x0000000080050033, shadow=0x0000000060000010, >> gh_mask=ffffffffffffffff >> (XEN) CR4: actual=0x0000000000002050, shadow=0x0000000000000000, >> gh_mask=fffffffffffff871 >> (XEN) CR3 = 0x00000000feffc000 >> (XEN) RSP = 0x0000000000000000 (0x0000000000000000) RIP = >> 0x000000000000fff0 (0x000000000000fff0) >> (XEN) RFLAGS=0x00010002 (0x00010002) DR7 = 0x0000000000000400 >> (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 >> (XEN) sel attr limit base >> (XEN) CS: f000 0009b 0000ffff 00000000ffff0000 >> (XEN) DS: 0000 00093 0000ffff 0000000000000000 >> (XEN) SS: 0000 00093 0000ffff 0000000000000000 >> (XEN) ES: 0000 00093 0000ffff 0000000000000000 >> (XEN) FS: 0000 00093 0000ffff 0000000000000000 >> (XEN) GS: 0000 00093 0000ffff 0000000000000000 >> (XEN) GDTR: 0000ffff 0000000000000000 >> (XEN) LDTR: 0000 00082 0000ffff 0000000000000000 >> (XEN) IDTR: 0000ffff 0000000000000000 >> (XEN) TR: 0000 0008b 0000ffff 0000000000000000 >> (XEN) EFER(VMCS) = 0x0000000000000000 PAT = 0x0000050100070406 >> (XEN) PreemptionTimer = 0x00000000 SM Base = 0x00000000 >> (XEN) DebugCtl = 0x0000000000000000 DebugExceptions = 0x0000000000000000 >> (XEN) Interruptibility = 00000000 ActivityState = 00000000 >> (XEN) InterruptStatus = 0000 >> (XEN) *** Host State *** >> (XEN) RIP = 0xffff82d08030f8b0 (vmac.c#vmx_asm_vmexit_handler) RSP = >> 0xffff8320259bff70 > > Something is definitely strange in your build of Xen. vmac.c doesn't > contain the vmexit handler. > >> (XEN) CS=e008 SS=0000 DS=0000 ES=0000 FS=0000 GS=0000 TR=e040 >> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 TRBase=ffff8320259c2c00 >> (XEN) GDTBase=ffff8320259b2000 IDTBase=ffff8320259b6000 >> (XEN) CR0=0000000080050033 CR3=000000201bc45000 CR4=00000000003526e0 >> (XEN) Sysenter RSP=ffff8320259bffa0 CS:RIP=e008:ffff82d080354420 >> (XEN) EFER = 0x0000000000000d01 PAT = 0x0000050100070406 >> (XEN) *** Control State *** >> (XEN) PinBased=0000003f CPUBased=b6a1edfa SecondaryExec=000214eb >> (XEN) EntryControls=000011ff ExitControls=002fefff >> (XEN) ExceptionBitmap=00060042 PFECmask=00000000 PFECmatch=00000000 >> (XEN) VMEntry: intr_info=8000030d errcode=00000000 ilen=00000000 >> (XEN) VMExit: intr_info=00000000 errcode=00000000 ilen=00000005 >> (XEN) reason=00000030 qualification=0000000000000181 >> (XEN) IDTVectoring: info=80000b0d errcode=0000f000 > > The IDTVectoring and VMEntry fields look like we intercepted a page > fault, but are trying to re-inject it without an error code, which is > possibly what hardware is complaining about. I think it's an EPT violation that we caught, which must have happened while trying to deliver #GP(0xf000). That's rather odd in real mode. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel

©2013 Xen Project, A Linux Foundation Collaborative Project. All Rights Reserved.
Linux Foundation is a registered trademark of The Linux Foundation.
Xen Project is a trademark of The Linux Foundation.