From owner-freebsd-xen@freebsd.org Mon May 21 09:03:28 2018 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73792EEA34C for ; Mon, 21 May 2018 09:03:28 +0000 (UTC) (envelope-from prvs=6724271a8=roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.ctxuk.citrix.com [185.25.65.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.citrix.com", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 06BBD74F76; Mon, 21 May 2018 09:03:25 +0000 (UTC) (envelope-from prvs=6724271a8=roger.pau@citrix.com) X-IronPort-AV: E=Sophos;i="5.49,426,1520899200"; d="scan'208";a="73449245" Date: Mon, 21 May 2018 11:03:10 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Pratyush Yadav CC: , Akshay Jaggi , Edward Napierala Subject: Re: Xen kernel fails to boot, d0v1 triple fault looks like the cuplrit Message-ID: <20180521090310.c46eexnwe4c7w62x@MacBook-Pro-de-Roger.local> References: <20180519081030.qhzyjdrpwcekmcac@MacBook-Pro-de-Roger.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180323 X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 09:03:28 -0000 Please try to avoid top posting. On Sat, May 19, 2018 at 03:45:41PM +0530, Pratyush Yadav wrote: > Hi, > > The line is > > /usr/src/sys/amd64/amd64/mp_machdep.c:307 Hm, it seems like dbg_stack is not properly allocated. Can you please try the above debug patch and paste the boot log? ---8<--- diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c index 301461420874..8854242b4bf5 100644 --- a/sys/amd64/amd64/mp_machdep.c +++ b/sys/amd64/amd64/mp_machdep.c @@ -304,6 +304,7 @@ init_secondary(void) /* Save the per-cpu pointer for use by the DB# handler. */ np = ((struct nmi_pcpu *) &dbg_stack[PAGE_SIZE]) - 1; +printf("ID %d dbg_stack: %p per-cpu: %p\n", cpu, dbg_stack, np); np->np_pcpu = (register_t) pc; wrmsr(MSR_FSBASE, 0); /* User value */ @@ -403,6 +404,7 @@ native_start_all_aps(void) M_WAITOK | M_ZERO); dbg_stack = (char *)kmem_malloc(kernel_arena, PAGE_SIZE, M_WAITOK | M_ZERO); +printf("allocated dbg_stack: %p\n", dbg_stack); dpcpu = (void *)kmem_malloc(kernel_arena, DPCPU_SIZE, M_WAITOK | M_ZERO); From owner-freebsd-xen@freebsd.org Mon May 21 19:51:17 2018 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6A17EFCECB for ; Mon, 21 May 2018 19:51:17 +0000 (UTC) (envelope-from nathan.friess@gmail.com) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 21E4B6DB0E; Mon, 21 May 2018 19:51:17 +0000 (UTC) (envelope-from nathan.friess@gmail.com) Received: by mail-pf0-x243.google.com with SMTP id p12-v6so7565366pff.13; Mon, 21 May 2018 12:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=YMSr36fmh9IuqrNTeoP9YDkQOCxqk9m/DbJd7YcYRxQ=; b=mWLBUSeTBsCjx+0YRGqi0OGpsZjGi+orBktLRjCR+bb/Kb7KyUA4QKSDFmxm6v8HK9 B5CDVk5NKmkpZCIDQ+w7Q8Q5wNu8cOeohz3yS/Q/7TS63x9Bj7y3H1zHm8iEh4PQSWBR RPjMfMetx3rk6NiM2W8/zXNQfoREEW+EVj+p3e5aOKJAmhaphRKnsqGQFRF2S0X+7NW2 6FKGDc+A54He8tJQSPfv9ZpFnWAJUyW6r2J2AeFvYj+14nNhF4K41kqL8DOcQzJ9SGaa 3HxWy7ahRriNAy9jL7RDyS+hjuS5iLU/gdLhGoDXWhPYDCauZho9i2VNGBE+QQcVmoep GjFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=YMSr36fmh9IuqrNTeoP9YDkQOCxqk9m/DbJd7YcYRxQ=; b=OpUjP/FbOQmj99cRo8r8O/yDSL1kpfOHqJF5Uy8JenwqB+9mDGNsQkHJxYokrbryCh KkV+C6fdk49YmLiNlrGrat3nUqHMtddH4uTr55WGoO1ieGRTdrDJX+tL5nRKk4fUjTjR tDaZeQj/uIaYniRU/GGXFi6ITwCfSKUJRa8xi19aTbVGUnI9V1U/rRLA1sJgKDmX94I0 PYDHWI8XcGWJrHaEePxEc0QUsx7MYcx4G7QTnLQ+eSYIpYY7dP5mEGywO1UFj4eyKuqJ WTRotv4SPd3qwwA7SX/WWRipbGjYgP+B4V6gzW1TBgpGbH2MSpeL64hqKe11hb0YDRpb 6PGQ== X-Gm-Message-State: ALKqPwcH0hEyArcjetE1gUeiVBBl01wujGsEdjH/AkBhfU2DcdNkPLnR C/+G0egT+5l39BdGqyjrlP+smSmJ X-Google-Smtp-Source: AB8JxZrMRORMag9rwKiFgQzpi080m+tYruYCbgJXMa6caZzo0du9EqFZKOgdbuRK+nRe5GUfaMw7EA== X-Received: by 2002:a62:66dd:: with SMTP id s90-v6mr21041099pfj.123.1526932275857; Mon, 21 May 2018 12:51:15 -0700 (PDT) Received: from [10.2.1.1] (S01060018e7c4b870.cg.shawcable.net. [70.72.182.108]) by smtp.gmail.com with ESMTPSA id k193-v6sm18692950pgc.39.2018.05.21.12.51.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 May 2018 12:51:15 -0700 (PDT) Subject: Re: Linux domU only works with xen_platform_pci=0 ? To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Cc: freebsd-xen@freebsd.org References: <20180513151649.4ls73myegkhm3cep@MacBook-Pro-de-Roger.local> <0749df4b-1614-dcdf-1bf2-1bbad1ae5743@duckster.net> <20180514130445.ahqk5ol3kdhriqju@MacBook-Pro-de-Roger.local> <6c0e1f5a-3e7d-054e-298c-5ec3d97e6141@gmail.com> <20180515080836.kufr3q3mk5mxwx4q@MacBook-Pro-de-Roger.local> <20180519080250.67fl66gqbew7xfzp@MacBook-Pro-de-Roger.local> From: Nathan Friess Message-ID: <723f10d0-62c0-e48e-e8f4-b137378f0a25@gmail.com> Date: Mon, 21 May 2018 13:51:13 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180519080250.67fl66gqbew7xfzp@MacBook-Pro-de-Roger.local> Content-Type: multipart/mixed; boundary="------------8503B0B82DD575571FB6E3F0" Content-Language: en-US X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 19:51:18 -0000 This is a multi-part message in MIME format. --------------8503B0B82DD575571FB6E3F0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2018-05-19 02:02 AM, Roger Pau Monné wrote: > On Thu, May 17, 2018 at 06:10:15PM -0600, Nathan Friess wrote: >> I tried the patch on and I my Linux domU did was not able to complete the >> attachment to the FreeBSD backend. I applied the patch to the 11-RELEASE >> kernel. (I couldn't get 11-STABLE to compile.) >> >> With xen_platform_pci=0 the frontend and backend vbds were both stuck in >> state 1. With xen_platform_pci=1 the frontend was in state 1 and backend in >> state 3. > > Thanks for the testing! I however think you had some issue applying > the patch or building/installing the kernel, with the attached patch > the backend should never go into state 3. > > Can you confirm that you have the patch correctly applied to the > kernel you are running? > > And if so, can you try to debug why the backend goes into state 3? > > FWIW, the patch works fine for me and I've been able to boot Debian > and Alpine Linux guests without having to add xen_platform_pci=0. > > Thanks, Roger. > Sorry, I don't which run I was looking at there. Here is the order of events. There are two zvols exposed to the domU, /dev/zvol/zroot/vmachines/smyth/rootfs and .../swap, so the messages are interspersed between the two. xbb(xbb_attach:3738): Attaching to backend/vbd/10/51713 xbb(xbb_attach:3802): Attach done, set state InitWait xbb(xbb_attach_disk:3612): Enter xbb_attach_disk xbb(xbb_attach_disk:3620): Read physical-device-path failed xbb(xbb_frontend_changed:3918): frontend_state=Initialising, xbb_state=InitWait xbb(xbb_attach:3738): Attaching to backend/vbd/10/51714 xbb(xbb_attach:3802): Attach done, set state InitWait xbb(xbb_attach_disk:3612): Enter xbb_attach_disk xbb(xbb_attach_disk:3620): Read physical-device-path failed xbb(xbb_frontend_changed:3918): frontend_state=Initialising, xbb_state=InitWait (Shell script) Start block script /local/domain/9/backend/vbd/10/51714 add (Shell script) Start block script /local/domain/9/backend/vbd/10/51713 add [1] xbb(xbb_frontend_changed:3918): frontend_state=Initialised, xbb_state=InitWait xbb(xbb_connect:3316): Enter xbb_connect: hotplug=0, get_state=2, collect_frontend=0 [1] xbb(xbb_frontend_changed:3918): frontend_state=Initialised, xbb_state=InitWait xbb(xbb_connect:3316): Enter xbb_connect: hotplug=0, get_state=2, collect_frontend=0 (Shell script) Write /dev/zvol/zroot/vmachines/smyth/rootfs to /local/domain/9/backend/vbd/10/51713/physical-device-path xbb(xbb_attach_disk:3612): Enter xbb_attach_disk xbb(xbb_open_backend:2687): opening dev=/dev/zvol/zroot/vmachines/smyth/rootfs xbb(xbb_open_backend:2757): opened dev=/dev/zvol/zroot/vmachines/smyth/rootfs sector_size=512 media_size=21474836480 xbb(xbb_attach_disk:3718): Set hotplug done, attach_disk done (Shell script) Write /dev/zvol/zroot/vmachines/smyth/swap to /local/domain/9/backend/vbd/10/51714/physical-device-path xbb(xbb_attach_disk:3612): Enter xbb_attach_disk xbb(xbb_open_backend:2687): opening dev=/dev/zvol/zroot/vmachines/smyth/swap xbb(xbb_open_backend:2757): opened dev=/dev/zvol/zroot/vmachines/smyth/swap sector_size=512 media_size=2147483648 xbb(xbb_attach_disk:3718): Set hotplug done, attach_disk done ... is stuck here... At [1] the frontend has transitioned to Initialised but the block script has not completed yet so hotplug_done is 0 and the notification about the frontend status change is lost. Calling xbb_connect at the end of xbb_attach_disk like in the attached patch will catch this case. Now with your recent change and the attached file I can use Linux domUs successfully! On a related note, did these patches ever make it into 11-stable? I don't see them at svn.freebsd.org/base/stable/11 but I may have missed something. https://lists.freebsd.org/pipermail/freebsd-xen/2016-December/002918.html There were 4 patches, the third one being required for xl devd to trigger block scripts. I have been using them as well for over a year with no issues: https://lists.freebsd.org/pipermail/freebsd-xen/2016-December/002918.html Thanks, Nathan --------------8503B0B82DD575571FB6E3F0 Content-Type: text/x-patch; name="missed-watch2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="missed-watch2.patch" --- blkback.c.orig2 2018-05-21 06:37:22.421962000 -0600 +++ blkback.c 2018-05-21 06:38:27.571800000 -0600 @@ -3694,6 +3694,12 @@ } xbb->hotplug_done = true; + + /* The front end may have finished first, so we should proceed as well. */ + if (xenbus_get_otherend_state(xbb->dev) == XenbusStateInitialised) { + xbb_connect(xbb); + } + } /** --------------8503B0B82DD575571FB6E3F0-- From owner-freebsd-xen@freebsd.org Tue May 22 09:01:36 2018 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04F46EEE4B3 for ; Tue, 22 May 2018 09:01:36 +0000 (UTC) (envelope-from royger@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A680A6ACF6; Tue, 22 May 2018 09:01:35 +0000 (UTC) (envelope-from royger@FreeBSD.org) Received: from localhost (138.red-95-120-31.dynamicip.rima-tde.net [95.120.31.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: royger) by smtp.freebsd.org (Postfix) with ESMTPSA id 922651D641; Tue, 22 May 2018 09:01:34 +0000 (UTC) (envelope-from royger@FreeBSD.org) Date: Tue, 22 May 2018 11:01:24 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Nathan Friess Cc: freebsd-xen@freebsd.org Subject: Re: Linux domU only works with xen_platform_pci=0 ? Message-ID: <20180522090124.onimqynage4hys53@MBP-de-Roger> References: <20180513151649.4ls73myegkhm3cep@MacBook-Pro-de-Roger.local> <0749df4b-1614-dcdf-1bf2-1bbad1ae5743@duckster.net> <20180514130445.ahqk5ol3kdhriqju@MacBook-Pro-de-Roger.local> <6c0e1f5a-3e7d-054e-298c-5ec3d97e6141@gmail.com> <20180515080836.kufr3q3mk5mxwx4q@MacBook-Pro-de-Roger.local> <20180519080250.67fl66gqbew7xfzp@MacBook-Pro-de-Roger.local> <723f10d0-62c0-e48e-e8f4-b137378f0a25@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <723f10d0-62c0-e48e-e8f4-b137378f0a25@gmail.com> User-Agent: NeoMutt/20180323 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 09:01:36 -0000 On Mon, May 21, 2018 at 01:51:13PM -0600, Nathan Friess wrote: > On 2018-05-19 02:02 AM, Roger Pau Monné wrote: > > On Thu, May 17, 2018 at 06:10:15PM -0600, Nathan Friess wrote: > > > I tried the patch on and I my Linux domU did was not able to complete the > > > attachment to the FreeBSD backend. I applied the patch to the 11-RELEASE > > > kernel. (I couldn't get 11-STABLE to compile.) > > > > > > With xen_platform_pci=0 the frontend and backend vbds were both stuck in > > > state 1. With xen_platform_pci=1 the frontend was in state 1 and backend in > > > state 3. > > > > Thanks for the testing! I however think you had some issue applying > > the patch or building/installing the kernel, with the attached patch > > the backend should never go into state 3. > > > > Can you confirm that you have the patch correctly applied to the > > kernel you are running? > > > > And if so, can you try to debug why the backend goes into state 3? > > > > FWIW, the patch works fine for me and I've been able to boot Debian > > and Alpine Linux guests without having to add xen_platform_pci=0. > > > > Thanks, Roger. > > > > Sorry, I don't which run I was looking at there. Here is the order of > events. There are two zvols exposed to the domU, > /dev/zvol/zroot/vmachines/smyth/rootfs and .../swap, so the messages are > interspersed between the two. > > xbb(xbb_attach:3738): Attaching to backend/vbd/10/51713 > xbb(xbb_attach:3802): Attach done, set state InitWait > xbb(xbb_attach_disk:3612): Enter xbb_attach_disk > xbb(xbb_attach_disk:3620): Read physical-device-path failed > xbb(xbb_frontend_changed:3918): frontend_state=Initialising, > xbb_state=InitWait > xbb(xbb_attach:3738): Attaching to backend/vbd/10/51714 > xbb(xbb_attach:3802): Attach done, set state InitWait > xbb(xbb_attach_disk:3612): Enter xbb_attach_disk > xbb(xbb_attach_disk:3620): Read physical-device-path failed > xbb(xbb_frontend_changed:3918): frontend_state=Initialising, > xbb_state=InitWait > (Shell script) Start block script /local/domain/9/backend/vbd/10/51714 add > (Shell script) Start block script /local/domain/9/backend/vbd/10/51713 add > [1] xbb(xbb_frontend_changed:3918): frontend_state=Initialised, > xbb_state=InitWait > xbb(xbb_connect:3316): Enter xbb_connect: hotplug=0, get_state=2, > collect_frontend=0 > [1] xbb(xbb_frontend_changed:3918): frontend_state=Initialised, > xbb_state=InitWait > xbb(xbb_connect:3316): Enter xbb_connect: hotplug=0, get_state=2, > collect_frontend=0 > (Shell script) Write /dev/zvol/zroot/vmachines/smyth/rootfs to > /local/domain/9/backend/vbd/10/51713/physical-device-path > xbb(xbb_attach_disk:3612): Enter xbb_attach_disk > xbb(xbb_open_backend:2687): opening > dev=/dev/zvol/zroot/vmachines/smyth/rootfs > xbb(xbb_open_backend:2757): opened > dev=/dev/zvol/zroot/vmachines/smyth/rootfs sector_size=512 > media_size=21474836480 > xbb(xbb_attach_disk:3718): Set hotplug done, attach_disk done > (Shell script) Write /dev/zvol/zroot/vmachines/smyth/swap to > /local/domain/9/backend/vbd/10/51714/physical-device-path > xbb(xbb_attach_disk:3612): Enter xbb_attach_disk > xbb(xbb_open_backend:2687): opening dev=/dev/zvol/zroot/vmachines/smyth/swap > xbb(xbb_open_backend:2757): opened dev=/dev/zvol/zroot/vmachines/smyth/swap > sector_size=512 media_size=2147483648 > xbb(xbb_attach_disk:3718): Set hotplug done, attach_disk done > > ... is stuck here... > > At [1] the frontend has transitioned to Initialised but the block script has > not completed yet so hotplug_done is 0 and the notification about the > frontend status change is lost. Calling xbb_connect at the end of > xbb_attach_disk like in the attached patch will catch this case. Now with > your recent change and the attached file I can use Linux domUs successfully! Your Linux kernel is certainly very fast to boot, so that it wins the race with blkback processing the result from the hotplug script execution. I've now committed the fix to HEAD, will MFC in a week if everything goes fine: https://svnweb.freebsd.org/base?view=revision&revision=334027 TYVM for the testing and the fix. > On a related note, did these patches ever make it into 11-stable? I don't > see them at svn.freebsd.org/base/stable/11 but I may have missed something. > > https://lists.freebsd.org/pipermail/freebsd-xen/2016-December/002918.html I don't think they are on HEAD either? I don't have a lot of time ATM, so if you want to pick the patches, rebase them onto HEAD, test them and give me a branch I'm more than happy to review and commit them. > There were 4 patches, the third one being required for xl devd to trigger > block scripts. I have been using them as well for over a year with no > issues: > > https://lists.freebsd.org/pipermail/freebsd-xen/2016-December/002918.html The Xen side of this is already upstream AFAIK, see: http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=7ff99b232e0f91a5189f429498868bfccf8d7154 Thanks, Roger. From owner-freebsd-xen@freebsd.org Wed May 23 07:28:42 2018 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C152EF2DEB for ; Wed, 23 May 2018 07:28:42 +0000 (UTC) (envelope-from pratiy0100@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 607407B9CD; Wed, 23 May 2018 07:28:41 +0000 (UTC) (envelope-from pratiy0100@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id o78-v6so6334942wmg.0; Wed, 23 May 2018 00:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ymyWJCD4okRKDkVpTT9tVLtYgns3nHDusTml2hTLv0g=; b=dENQJB2wcWhG4NDoFquOJW9ycpkAOa9FoGzXBIxGnP3ahYXWoDk55H7QVIvKKiTJQO MLAnePSq+x6ZGhHX2yXmAzN0X2w2NADezZiWyKaiSGCFqPVz+3WbecOpGu3zJ2n5vO6+ 6Q/X/PpgZysI2chM7zM2B2QIEfzk7AYNZX5ZDzfFmig0Pz+CZsz2kS04LtMOjJ9VVDlH yaohEqMvpyOP/v9hhXeLc9sf6bmCHvpWNU/zZzBEF5ri/JjQ71KXmORDIRgeIETQL0uv Lo422b3kS0vilKXmP0Gbx5Lw//Q3QKR5xGdwG4FTERDqiU0nx3QuJxIGyfInV9fW5eGV +9rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ymyWJCD4okRKDkVpTT9tVLtYgns3nHDusTml2hTLv0g=; b=Il9Ag4MdXWSQY6EpI8WWFXmIVDsccqAwOZQhj3R/G0B8ML6WDOtNyPvAD1Z/ctniBr J+wJqDkoJxqseKr/EqDihBclilIVzIVSAKk35doctMGcSaC73nCdzAZ9jD3gvMCQnzcW +QvkhKXVqnT6wDf4tSAYIaiFGZJqz2tkTW9l7AHSrRWW4/59CtxzwrSUzKkNO2LHToaD jy1pN/aw6jn5OhvExPAVv36kVssacbcrki4JKfnOOO9/hmgbJmDiJIWH1fqbtAIRdV0O VkO9wgZW6YiqSh4JBVabd1APBFliWgb1cGSpy+wEkquIZctVSrLRL4ctXmb0UWa+mA1t sAZw== X-Gm-Message-State: ALKqPwfPtLVoC2n9t6ZxdhFMWQ2hRy7GzatsqCvOw5pRYDS+JqdtBUB6 PjVedlx9yz30R6bmie62AcywvGDr9xdi31bTZJIGEBVp X-Google-Smtp-Source: AB8JxZoyOfVzo7K9b8wJapegSnzOWL5BLzFaJ4LnoVSnhcm/uA6i4twiERiqP49YuFFHthnSmMGhrhEAYh5cH2OXq+o= X-Received: by 2002:a50:9953:: with SMTP id l19-v6mr5863997edb.179.1527060519895; Wed, 23 May 2018 00:28:39 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:aa21:0:0:0:0:0 with HTTP; Wed, 23 May 2018 00:27:59 -0700 (PDT) In-Reply-To: <20180521090310.c46eexnwe4c7w62x@MacBook-Pro-de-Roger.local> References: <20180519081030.qhzyjdrpwcekmcac@MacBook-Pro-de-Roger.local> <20180521090310.c46eexnwe4c7w62x@MacBook-Pro-de-Roger.local> From: Pratyush Yadav Date: Wed, 23 May 2018 12:57:59 +0530 Message-ID: Subject: Re: Xen kernel fails to boot, d0v1 triple fault looks like the cuplrit To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: FreeBSD-Xen , Akshay Jaggi , Edward Napierala Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 07:28:42 -0000 On Mon, May 21, 2018 at 2:33 PM, Roger Pau Monn=C3=A9 wrote: > Please try to avoid top posting. Sorry, I didn't know. I Googled top posting just now, and realized it is inconvenient for the reader. > Hm, it seems like dbg_stack is not properly allocated. Can you please > try the above debug patch and paste the boot log? > > ---8<--- > diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c > index 301461420874..8854242b4bf5 100644 > --- a/sys/amd64/amd64/mp_machdep.c > +++ b/sys/amd64/amd64/mp_machdep.c > @@ -304,6 +304,7 @@ init_secondary(void) > > /* Save the per-cpu pointer for use by the DB# handler. */ > np =3D ((struct nmi_pcpu *) &dbg_stack[PAGE_SIZE]) - 1; > +printf("ID %d dbg_stack: %p per-cpu: %p\n", cpu, dbg_stack, np); > np->np_pcpu =3D (register_t) pc; > > wrmsr(MSR_FSBASE, 0); /* User value */ > @@ -403,6 +404,7 @@ native_start_all_aps(void) > M_WAITOK | M_ZERO); > dbg_stack =3D (char *)kmem_malloc(kernel_arena, PAGE_SIZE= , > M_WAITOK | M_ZERO); > +printf("allocated dbg_stack: %p\n", dbg_stack); > dpcpu =3D (void *)kmem_malloc(kernel_arena, DPCPU_SIZE, > M_WAITOK | M_ZERO); > I applied your patch. The boot stops at the same spot. Also, I can't see any of the two print messages added in the patch. I booted from a Live CD to look at the logs, but they are not stored. I checked dmesg.boot and messages, and /var/log/xen/ none of them have the logs. They all have logs of the previous boot. This is all what I can see from my screen: XEN) Scrubbing free RAM on 1 nodes using 4 CPUs (XEN) [VT-D] DMAR: [DMA Read} Request device [0000:00:1a.0] fault addr 9ce13000. iommu reg - ffff82c000203000 (XEN) [VT-D] DMAR: reason 06 - PTE read access is not set (XEN) ........... done (XEN) initial low memory virq threshold set at 0x200 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) Xen is keeping VGA console (XEN) Boot video device 00:02.0 (XEN) ***Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 320 kB init memory FreeBSD PVH running on xen-3.0-x86_64p Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #0 r333974M: Wed May 11 37:05 IST 2018 root@freebsd-test:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 WARNING: WITNESS option enabled, expect reduced performance. VT(vga): text 80x25 CPU: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz (2494.22-MHz K8-class CPU) Origin=3D"GenuineIntel" Id=3D0x306c3 Family=3D0x6 Model=3D0x3c Stepping= =3D3 Features=3D0x17c1cbf5 Features2=3D0xf6f83203 AMD Features=3D0x20101800NX,LM> AMD Features2=3D0x21< Structured Extended Features=3D0x2329 Hypervisor: Origin =3D "XenVMMXenVMM" real memory =3D 5982789632 (5705 MB) avail memory =3D 4051214336 (3863 MB) (XEN) d0v1 Triple fault - invoking HVM shutdown action 0 (XEN) *** Dumping Dom0 vcpu#1 state: *** (XEN) ----[ Xen-4.7.2 x86_64 debug=3Dn Not tainted ]---- (XEN) CPU: 1 (XEN) RIP: 0020:[] (XEN) RFLAGS: 0000000000010046 CONTEXT: hvm guest (d0v1) (XEN) rax: 0000000000000000 rbx: fffff801649a1ff8 rcx: 00000000000000c7 (XEN) rdx: ffffffff81b166f0 rsi: 0000000000000000 rdi: fffff801649a1ff8 (XEN) rbp: fffffe00027e8bb0 rsp: fffffe0027e8b80 r8: fefefefefefefeff (XEN) r15: ffffffff812f497c cr0: 0000000000000011 cr4: 0000000000000020 (XEN) cr3: 0000000002e36000 cr2: 0000000000000000 (XEN) ds: 0028 es: 0028 fs: 0028 gs: 0028 ss: 0028 cs: 0020 (XEN) Guest stack trace from rsp=3Dfffffe00009fffa0: (XEN) Fault while accessing guest memory. (XEN) Hardware Dom0 halted: halting machine When I run addr2line on ffffffff80b52fbe, I get: ./machine/pcpu.h:231 --=20 Regards, Pratyush Yadav From owner-freebsd-xen@freebsd.org Wed May 23 08:16:03 2018 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A2F7EF4728 for ; Wed, 23 May 2018 08:16:03 +0000 (UTC) (envelope-from prvs=674474304=roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.eu.citrix.com [185.25.65.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.citrix.com", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 571857DD8A; Wed, 23 May 2018 08:16:02 +0000 (UTC) (envelope-from prvs=674474304=roger.pau@citrix.com) X-IronPort-AV: E=Sophos;i="5.49,432,1520899200"; d="scan'208";a="73570958" Date: Wed, 23 May 2018 10:15:47 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Pratyush Yadav CC: FreeBSD-Xen , Akshay Jaggi , Edward Napierala Subject: Re: Xen kernel fails to boot, d0v1 triple fault looks like the cuplrit Message-ID: <20180523081547.2vvthg42vmphvbex@MacBook-Pro-de-Roger.local> References: <20180519081030.qhzyjdrpwcekmcac@MacBook-Pro-de-Roger.local> <20180521090310.c46eexnwe4c7w62x@MacBook-Pro-de-Roger.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180323 X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 08:16:03 -0000 On Wed, May 23, 2018 at 12:57:59PM +0530, Pratyush Yadav wrote: > On Mon, May 21, 2018 at 2:33 PM, Roger Pau Monné > wrote: > > Please try to avoid top posting. > > Sorry, I didn't know. I Googled top posting just now, and realized it is > inconvenient for the reader. > > > Hm, it seems like dbg_stack is not properly allocated. Can you please > > try the above debug patch and paste the boot log? > > > > ---8<--- > > diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c > > index 301461420874..8854242b4bf5 100644 > > --- a/sys/amd64/amd64/mp_machdep.c > > +++ b/sys/amd64/amd64/mp_machdep.c > > @@ -304,6 +304,7 @@ init_secondary(void) > > > > /* Save the per-cpu pointer for use by the DB# handler. */ > > np = ((struct nmi_pcpu *) &dbg_stack[PAGE_SIZE]) - 1; > > +printf("ID %d dbg_stack: %p per-cpu: %p\n", cpu, dbg_stack, np); > > np->np_pcpu = (register_t) pc; > > > > wrmsr(MSR_FSBASE, 0); /* User value */ > > @@ -403,6 +404,7 @@ native_start_all_aps(void) > > M_WAITOK | M_ZERO); > > dbg_stack = (char *)kmem_malloc(kernel_arena, PAGE_SIZE, > > M_WAITOK | M_ZERO); > > +printf("allocated dbg_stack: %p\n", dbg_stack); > > dpcpu = (void *)kmem_malloc(kernel_arena, DPCPU_SIZE, > > M_WAITOK | M_ZERO); > > > > I applied your patch. The boot stops at the same spot. Also, I can't see > any of the two print messages added in the patch. I booted from a Live CD > to look at the logs, but they are not stored. I checked dmesg.boot and > messages, and /var/log/xen/ none of them have the logs. They all have logs > of the previous boot. It's too early for the logs to be stored anywhere. The point where you get the crash is when the APs are started, which is way before FreeBSD starts proving for disk devices. Can you please try the patch below? Thanks, Roger. ---8<--- diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c index 54184898e9bf..52391e2e7c08 100644 --- a/sys/x86/xen/pv.c +++ b/sys/x86/xen/pv.c @@ -113,6 +113,7 @@ static int xen_pv_start_all_aps(void); extern char *doublefault_stack; extern char *mce_stack; extern char *nmi_stack; +extern char *dbg_stack; #endif /* @@ -329,6 +330,8 @@ start_xen_ap(int cpu) (char *)kmem_malloc(kernel_arena, PAGE_SIZE, M_WAITOK | M_ZERO); nmi_stack = (char *)kmem_malloc(kernel_arena, PAGE_SIZE, M_WAITOK | M_ZERO); + dbg_stack = + (void *)kmem_malloc(kernel_arena, PAGE_SIZE, M_WAITOK | M_ZERO); dpcpu = (void *)kmem_malloc(kernel_arena, DPCPU_SIZE, M_WAITOK | M_ZERO); From owner-freebsd-xen@freebsd.org Wed May 23 10:27:16 2018 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6355AEF81C0 for ; Wed, 23 May 2018 10:27:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EC574828B2 for ; Wed, 23 May 2018 10:27:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id B075FEF81BD; Wed, 23 May 2018 10:27:15 +0000 (UTC) Delivered-To: xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F337EF81BB for ; Wed, 23 May 2018 10:27:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DE86828AB for ; Wed, 23 May 2018 10:27:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 704FC1C1FC for ; Wed, 23 May 2018 10:27:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w4NAREeR085704 for ; Wed, 23 May 2018 10:27:14 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w4NARE9d085703 for xen@FreeBSD.org; Wed, 23 May 2018 10:27:14 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: xen@FreeBSD.org Subject: [Bug 213439] ifOutOctets are always zero for Xen xn interfaces Date: Wed, 23 May 2018 10:27:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eadler@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: xen@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 10:27:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213439 Eitan Adler changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Open --- Comment #10 from Eitan Adler --- batch change of PRs untouched in 2018 marked "in progress" back to open. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-xen@freebsd.org Wed May 23 10:33:20 2018 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 829D4EF8BA6 for ; Wed, 23 May 2018 10:33:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 145CA83570 for ; Wed, 23 May 2018 10:33:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id C1E3DEF8BA3; Wed, 23 May 2018 10:33:19 +0000 (UTC) Delivered-To: xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ADA4CEF8BA2 for ; Wed, 23 May 2018 10:33:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45DAF8356A for ; Wed, 23 May 2018 10:33:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 8F46D1C43D for ; Wed, 23 May 2018 10:33:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w4NAXIcL004637 for ; Wed, 23 May 2018 10:33:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w4NAXIvZ004636 for xen@FreeBSD.org; Wed, 23 May 2018 10:33:18 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: xen@FreeBSD.org Subject: [Bug 213439] ifOutOctets are always zero for Xen xn interfaces Date: Wed, 23 May 2018 10:33:18 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: Trond.Endrestol@ximalas.info X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: xen@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 10:33:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213439 Trond.Endrestol@ximalas.info changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |Closed Resolution|--- |FIXED --- Comment #11 from Trond.Endrestol@ximalas.info --- (In reply to Eitan Adler from comment #10) The patch was committed a long time ago, and everything's fine as far as I = can tell. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-xen@freebsd.org Wed May 23 14:58:11 2018 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32D5FEFFABB for ; Wed, 23 May 2018 14:58:11 +0000 (UTC) (envelope-from pratiy0100@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9CAAA6EC94 for ; Wed, 23 May 2018 14:58:10 +0000 (UTC) (envelope-from pratiy0100@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id w194-v6so9825172wmf.2 for ; Wed, 23 May 2018 07:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pcNDOZHOQiukK+v0/ndo/BNaUQo/hR0XcKbENse1pwM=; b=SJWdj02u10kUwqBUALJTfc/APpmnRYNOVxUdRRj3CG5Dvy82fDd/mlR4O6kMeLnEji A4eYqyIgSGhwWF7qt01RkJmFFBdvCmUn4Bl7gWtGJuOXrgxWzLtNjxKvAULMZPwTHNy+ v1zqq4aahCGqG1OPDo1FAkNSdgHfRyoXnR6btl+HikX0MMhJBg+nBQIU9S4izMpVUBOb 8nx+7/DR+Z5Ry5yjZLCw2XeZ3cuBefYBBEazdmnFvuU+BWYLJYgABFtXbaNyx0NXvdRx ZDYS3vbqUVCRzb94GGkv/V2jbP3tOAxj7E6c6/k3y8hpqnPmXUzePm2aQK4gIaTIAV/T lubg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=pcNDOZHOQiukK+v0/ndo/BNaUQo/hR0XcKbENse1pwM=; b=Al+rrqDf3ODnkvfpPWpQfAuTzP1WpN+s1qWIiN7hz99gYgkq3gHSV3lr0ePEeR6cz3 +qdbliFoC+iFZuhGMUI23zULblQTfL1oL6pr71/Sn3m7GtpNDe/ig+roFQ9a+3JR8Lj7 OMo93rHwfebNJ3bu0S7PwU1ED0EnetWSuh4HL6wWh3VBjk/3O/w/GmPNVjKGuTX29DI2 fpy+yyXMgquhUv77BiKLcOywW/jvmlljvtnyt3UqKLbcXHux9dbfkbZYMpZLnfg9LUKZ SMUqe6YhdIOueJDxzELt00vNa2B0Tn9MGZxBBRgvBUGJXndlvawqryGDQBn4tKHDDQ73 MGZA== X-Gm-Message-State: ALKqPwdA3J3jdwrVZlHsVERoPL4viRbge1hywVL5GPxBScZp/xHt4rE9 J3lYveKwXUoxAmoW+g25e3EoZMJ0fhWZnN+itcO66HCF X-Google-Smtp-Source: AB8JxZqZn7vcbL7cT1a9YDelUki2gfnPCl53jk0nMLiwB6may/39zffbpGrqIhV7YA4/F4xE8kWo7vV4LHThj+Im7xU= X-Received: by 2002:aa7:c0c9:: with SMTP id j9-v6mr7594299edp.136.1527087489636; Wed, 23 May 2018 07:58:09 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:aa21:0:0:0:0:0 with HTTP; Wed, 23 May 2018 07:57:29 -0700 (PDT) In-Reply-To: <20180523081547.2vvthg42vmphvbex@MacBook-Pro-de-Roger.local> References: <20180519081030.qhzyjdrpwcekmcac@MacBook-Pro-de-Roger.local> <20180521090310.c46eexnwe4c7w62x@MacBook-Pro-de-Roger.local> <20180523081547.2vvthg42vmphvbex@MacBook-Pro-de-Roger.local> From: Pratyush Yadav Date: Wed, 23 May 2018 20:27:29 +0530 Message-ID: Subject: Re: Xen kernel fails to boot, d0v1 triple fault looks like the cuplrit To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: FreeBSD-Xen Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 14:58:11 -0000 Hi, On Wed, May 23, 2018 at 1:45 PM, Roger Pau Monn=C3=A9 wrote: > It's too early for the logs to be stored anywhere. The point where you > get the crash is when the APs are started, which is way before FreeBSD > starts proving for disk devices. > > Can you please try the patch below? > > Thanks, Roger. > ---8<--- > diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c > index 54184898e9bf..52391e2e7c08 100644 > --- a/sys/x86/xen/pv.c > +++ b/sys/x86/xen/pv.c > @@ -113,6 +113,7 @@ static int xen_pv_start_all_aps(void); > extern char *doublefault_stack; > extern char *mce_stack; > extern char *nmi_stack; > +extern char *dbg_stack; > #endif > > /* > @@ -329,6 +330,8 @@ start_xen_ap(int cpu) > (char *)kmem_malloc(kernel_arena, PAGE_SIZE, M_WAITOK | M_ZER= O); > nmi_stack =3D > (char *)kmem_malloc(kernel_arena, PAGE_SIZE, M_WAITOK | M_ZER= O); > + dbg_stack =3D > + (void *)kmem_malloc(kernel_arena, PAGE_SIZE, M_WAITOK | M_ZER= O); > dpcpu =3D > (void *)kmem_malloc(kernel_arena, DPCPU_SIZE, M_WAITOK | M_ZE= RO); > I think we have different pv.c files. For me, line 113 is: /* Xen init_ops implementation. */ The declarations of doublefault_stach, mce_stack, etc are in line 101. Similarly, line 329 for me is: { in function xen_pv_parse_symtab(void). The declarations your diff mentions in line 329 are in line 224. This is in sync with the official repository [0]. Maybe you have modifications that are not yet upstream? Anyway, I manually made the changes. It still does not boot (I used make kernel -DKERNFAST, but I don't think that should make a difference). Regards, Pratyush Yadav [0] https://github.com/freebsd/freebsd/blob/master/sys/x86/xen/pv.c From owner-freebsd-xen@freebsd.org Wed May 23 15:11:33 2018 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73343EFFE34 for ; Wed, 23 May 2018 15:11:33 +0000 (UTC) (envelope-from prvs=674474304=roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.eu.citrix.com [185.25.65.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.citrix.com", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7D8F6F298 for ; Wed, 23 May 2018 15:11:32 +0000 (UTC) (envelope-from prvs=674474304=roger.pau@citrix.com) X-IronPort-AV: E=Sophos;i="5.49,433,1520899200"; d="scan'208";a="73597901" Date: Wed, 23 May 2018 17:11:08 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Pratyush Yadav CC: FreeBSD-Xen Subject: Re: Xen kernel fails to boot, d0v1 triple fault looks like the cuplrit Message-ID: <20180523151108.cxize3bblbpw3ewc@MBP-de-Roger.citrite.net> References: <20180519081030.qhzyjdrpwcekmcac@MacBook-Pro-de-Roger.local> <20180521090310.c46eexnwe4c7w62x@MacBook-Pro-de-Roger.local> <20180523081547.2vvthg42vmphvbex@MacBook-Pro-de-Roger.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180323 X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 15:11:33 -0000 On Wed, May 23, 2018 at 08:27:29PM +0530, Pratyush Yadav wrote: > Hi, > > On Wed, May 23, 2018 at 1:45 PM, Roger Pau Monné wrote: > > It's too early for the logs to be stored anywhere. The point where you > > get the crash is when the APs are started, which is way before FreeBSD > > starts proving for disk devices. > > > > Can you please try the patch below? > > > > Thanks, Roger. > > ---8<--- > > diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c > > index 54184898e9bf..52391e2e7c08 100644 > > --- a/sys/x86/xen/pv.c > > +++ b/sys/x86/xen/pv.c > > @@ -113,6 +113,7 @@ static int xen_pv_start_all_aps(void); > > extern char *doublefault_stack; > > extern char *mce_stack; > > extern char *nmi_stack; > > +extern char *dbg_stack; > > #endif > > > > /* > > @@ -329,6 +330,8 @@ start_xen_ap(int cpu) > > (char *)kmem_malloc(kernel_arena, PAGE_SIZE, M_WAITOK | M_ZERO); > > nmi_stack = > > (char *)kmem_malloc(kernel_arena, PAGE_SIZE, M_WAITOK | M_ZERO); > > + dbg_stack = > > + (void *)kmem_malloc(kernel_arena, PAGE_SIZE, M_WAITOK | M_ZERO); > > dpcpu = > > (void *)kmem_malloc(kernel_arena, DPCPU_SIZE, M_WAITOK | M_ZERO); > > > > I think we have different pv.c files. For me, line 113 is: > /* Xen init_ops implementation. */ > > The declarations of doublefault_stach, mce_stack, etc are in line 101. > > Similarly, line 329 for me is: > { > > in function xen_pv_parse_symtab(void). The declarations your diff > mentions in line 329 are in line 224. > > This is in sync with the official repository [0]. Maybe you have > modifications that are not yet upstream? Sorry, I did indeed have other changes in pv.c. I'm appending the patch on top of current HEAD. > Anyway, I manually made the changes. It still does not boot (I used > make kernel -DKERNFAST, but I don't think that should make a > difference). FWIW, I think the recommended way is KERNFAST=1. Can you paste the error? I think you should no longer get a triple page fault in mp_machdep.c:307. Thanks, Roger. ---8<--- diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c index c7e97c5b2b63..27e98012302b 100644 --- a/sys/x86/xen/pv.c +++ b/sys/x86/xen/pv.c @@ -101,6 +101,7 @@ static int xen_pv_start_all_aps(void); extern char *doublefault_stack; extern char *mce_stack; extern char *nmi_stack; +extern char *dbg_stack; #endif /* @@ -224,6 +225,8 @@ start_xen_ap(int cpu) (char *)kmem_malloc(kernel_arena, PAGE_SIZE, M_WAITOK | M_ZERO); nmi_stack = (char *)kmem_malloc(kernel_arena, PAGE_SIZE, M_WAITOK | M_ZERO); + dbg_stack = + (void *)kmem_malloc(kernel_arena, PAGE_SIZE, M_WAITOK | M_ZERO); dpcpu = (void *)kmem_malloc(kernel_arena, DPCPU_SIZE, M_WAITOK | M_ZERO); From owner-freebsd-xen@freebsd.org Thu May 24 02:37:18 2018 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B372CEF5CA8 for ; Thu, 24 May 2018 02:37:17 +0000 (UTC) (envelope-from nathan.friess@gmail.com) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 408806D2A0; Thu, 24 May 2018 02:37:17 +0000 (UTC) (envelope-from nathan.friess@gmail.com) Received: by mail-pg0-x244.google.com with SMTP id p9-v6so62604pgc.9; Wed, 23 May 2018 19:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=5QjU72cZKDM0BzAqPELHtRd5NEoE1lwmFgD0Lecr8fI=; b=P7EKUM3Z/Yc4mqfzkQTWaNftwEAoxTyg6MSwuSoiwuKXD2ZPP09080MrkbT7LF2m7E YV9jJD5yPBloYXD0sUYAUHrfQWO8IbJFinf9SEN1oYwaUyArNc/p9AyscyIqaxEkEYWg AasQxBtr9YVNN3h7rPnd4eOiDMs3g5KkH/prmAT0N66S2IM87iKSxYZXpJUtlp7ATnA/ vPtNXzYifzWIjMsSOV2YqkRDoirf8ByVjIcvP1p3o7cjg4TJ12ZdSuD3xbenw+/J4Xr7 KYnKe3Ga7z4zQ3X2KrXJ3/X5WZpwkMIRIn5a9svTTjBs4rZ76IQTM+3nzPA0RSDU6aQU Kh9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=5QjU72cZKDM0BzAqPELHtRd5NEoE1lwmFgD0Lecr8fI=; b=qk2HR0tp0VM1bUtOrK+XNRjeSNKLAwI9HAn7lpvmBUwCE6qraXRKFWjjSEmV/AzkQz 9kbSb++VYJyIFqdkuPNj1BDI2SEZC2BxG1mDQAn8d4GxhqAEocbsrm4FprO7jjqYQqNc 4ENY9znpuvT5A2kk54K7beygTmRZIqQfQuCYGB0X6oUL9NGtAmoEeBRpd8sHGW5wcexz OKszbF/NyRu1SGII+c2VuZgbu2hRhbN6QFKMMYfuUlCJBxm9gBKiHX6r+B6hR+Et/yma Exc72LAn3Hvn96k/zIC1/DYrduRekdYT8H9AiAsdl19RbmX6aEorM2+0gy0M/40YTCq4 h7wQ== X-Gm-Message-State: ALKqPwf2oeDV9gA8/VocrHqtWNtQ5PBOLeEfFEAlen96wD5qbuWmpOOW AmZp002zDoa4sfwtA4b1j+WxI7W3 X-Google-Smtp-Source: AB8JxZqtQyU2PWQttOb7kHLZfgR2AdL2jPnJKs50UWliXIo44+K1Yo4A+piDbG2a08r5Uyo7RAu5cA== X-Received: by 2002:a63:b601:: with SMTP id j1-v6mr4292142pgf.335.1527129435427; Wed, 23 May 2018 19:37:15 -0700 (PDT) Received: from [10.2.1.1] (S01060018e7c4b870.cg.shawcable.net. [70.72.182.108]) by smtp.gmail.com with ESMTPSA id z131-v6sm29964319pgz.86.2018.05.23.19.37.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 May 2018 19:37:14 -0700 (PDT) Subject: Re: Linux domU only works with xen_platform_pci=0 ? To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Cc: freebsd-xen@freebsd.org References: <20180513151649.4ls73myegkhm3cep@MacBook-Pro-de-Roger.local> <0749df4b-1614-dcdf-1bf2-1bbad1ae5743@duckster.net> <20180514130445.ahqk5ol3kdhriqju@MacBook-Pro-de-Roger.local> <6c0e1f5a-3e7d-054e-298c-5ec3d97e6141@gmail.com> <20180515080836.kufr3q3mk5mxwx4q@MacBook-Pro-de-Roger.local> <20180519080250.67fl66gqbew7xfzp@MacBook-Pro-de-Roger.local> <723f10d0-62c0-e48e-e8f4-b137378f0a25@gmail.com> <20180522090124.onimqynage4hys53@MBP-de-Roger> From: Nathan Friess Message-ID: <3ee7f3e1-e46d-5fde-e2aa-37947ea25f0d@gmail.com> Date: Wed, 23 May 2018 20:37:13 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180522090124.onimqynage4hys53@MBP-de-Roger> Content-Type: multipart/mixed; boundary="------------FC2B5AB8B9B6ED6E154A90A5" Content-Language: en-US X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 02:37:18 -0000 This is a multi-part message in MIME format. --------------FC2B5AB8B9B6ED6E154A90A5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2018-05-22 03:01 AM, Roger Pau Monné wrote: > On Mon, May 21, 2018 at 01:51:13PM -0600, Nathan Friess wrote: >> On 2018-05-19 02:02 AM, Roger Pau Monné wrote: >> On a related note, did these patches ever make it into 11-stable? I don't >> see them at svn.freebsd.org/base/stable/11 but I may have missed something. >> >> https://lists.freebsd.org/pipermail/freebsd-xen/2016-December/002918.html > > I don't think they are on HEAD either? > > I don't have a lot of time ATM, so if you want to pick the patches, > rebase them onto HEAD, test them and give me a branch I'm more than > happy to review and commit them. > Attached are 4 patches from your git repository, applied to HEAD with some testing on an up-to-date 12-CURRENT install. I did see one kernel message that I assume is not fatal (more on that later). I'm not able to test running as dom0 right now because I don't have any newish hardware available. My main use case is FreeBSD as domU serving disks to other domUs. The 0001-0003 patches applied cleanly to HEAD. 0004 required moving a function around to fix a compile error but otherwise is unchanged. I also copied your commit messages from git into the patches for reference. I was going to attach a patch to fix xen-tools with iasl in 12-CURRENT, but as I type this I see that you just committed a fix yesterday. Thanks! :) The kernel message that I'm seeing appears when a domU shuts down or a disk is detached from a running domU, while the backend for the disk is my 12-CURRENT test system. The backend spits this out: lock order reversal: (sleepable after non-sleepable) 1st 0xfffff8000802fe90 xbbd1 (xbbd1) @ /usr/src/sys/dev/xen/blkback/blkback.c:3423 2nd 0xffffffff81fdf890 intrsrc (intrsrc) @ /usr/src/sys/x86/x86/intr_machdep.c:224 stack backtrace: #0 0xffffffff80bdd993 at witness_debugger+0x73 #1 0xffffffff80bdd814 at witness_checkorder+0xe34 #2 0xffffffff80b7d798 at _sx_xlock+0x68 #3 0xffffffff811b3913 at intr_remove_handler+0x43 #4 0xffffffff811c63ef at xen_intr_unbind+0x10f #5 0xffffffff80a12ecf at xbb_disconnect+0x2f #6 0xffffffff80a12e54 at xbb_shutdown+0x1e4 #7 0xffffffff80a10be4 at xbb_frontend_changed+0x54 #8 0xffffffff80ed66a4 at xenbusb_back_otherend_changed+0x14 #9 0xffffffff80a2a382 at xenwatch_thread+0x182 #10 0xffffffff80b34164 at fork_exit+0x84 #11 0xffffffff8101ec9e at fork_trampoline+0xe lock order reversal: (sleepable after non-sleepable) 1st 0xfffff80008030690 xbbd0 (xbbd0) @ /usr/src/sys/dev/xen/blkback/blkback.c:3423 2nd 0xffffffff81fdf890 intrsrc (intrsrc) @ /usr/src/sys/x86/x86/intr_machdep.c:224 stack backtrace: #0 0xffffffff80bdd993 at witness_debugger+0x73 #1 0xffffffff80bdd814 at witness_checkorder+0xe34 #2 0xffffffff80b7d798 at _sx_xlock+0x68 #3 0xffffffff811b3913 at intr_remove_handler+0x43 #4 0xffffffff811c63ef at xen_intr_unbind+0x10f #5 0xffffffff80a12ecf at xbb_disconnect+0x2f #6 0xffffffff80a12e54 at xbb_shutdown+0x1e4 #7 0xffffffff80a10be4 at xbb_frontend_changed+0x54 #8 0xffffffff80ed66a4 at xenbusb_back_otherend_changed+0x14 #9 0xffffffff80a2a382 at xenwatch_thread+0x182 #10 0xffffffff80b34164 at fork_exit+0x84 #11 0xffffffff8101ec9e at fork_trampoline+0xe Otherwise disk backends seem to work fine. Nathan --------------FC2B5AB8B9B6ED6E154A90A5 Content-Type: text/x-patch; name="0001-xenstore-remove-the-suspend-sx-lock.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-xenstore-remove-the-suspend-sx-lock.patch" >From 9f9ca8f244c773ee5e6a08efa6874890a8217f05 Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Thu, 15 Dec 2016 16:52:50 +0000 Subject: [PATCH 1/4] xenstore: remove the suspend sx lock There's no need to prevent suspend while doing xenstore transactions, callers of transactions are supposed to be prepared for a transaction to fail. This fixes a bug that could be triggered from the xenstore user-space device, since starting a transaction from user-space would result in returning there with a sx lock held, that causes a WITNESS check to trigger. Sponsored by: Citrix Systems R&D --- sys/dev/xen/xenstore/xenstore.c | 81 ++--------------------------------------- 1 file changed, 4 insertions(+), 77 deletions(-) diff --git a/sys/dev/xen/xenstore/xenstore.c b/sys/dev/xen/xenstore/xenstore.c index 4f89b74..14e4ebd 100644 =================================================================== --- a/sys/dev/xen/xenstore/xenstore.c (revision 334101) +++ b/sys/dev/xen/xenstore/xenstore.c (working copy) @@ -202,18 +202,6 @@ struct mtx watch_events_lock; /** - * Sleepable lock used to prevent VM suspension while a - * xenstore transaction is outstanding. - * - * Each active transaction holds a shared lock on the - * suspend mutex. Our suspend method blocks waiting - * to acquire an exclusive lock. This guarantees that - * suspend processing will only proceed once all active - * transactions have been retired. - */ - struct sx suspend_mutex; - - /** * The processid of the xenwatch thread. */ pid_t xenwatch_pid; @@ -710,50 +698,6 @@ } /*---------------- XenStore Message Request/Reply Processing -----------------*/ -/** - * Filter invoked before transmitting any message to the XenStore service. - * - * The role of the filter may expand, but currently serves to manage - * the interactions of messages with transaction state. - * - * \param request_msg_type The message type for the request. - */ -static inline void -xs_request_filter(uint32_t request_msg_type) -{ - if (request_msg_type == XS_TRANSACTION_START) - sx_slock(&xs.suspend_mutex); -} - -/** - * Filter invoked after transmitting any message to the XenStore service. - * - * The role of the filter may expand, but currently serves to manage - * the interactions of messages with transaction state. - * - * \param request_msg_type The message type for the original request. - * \param reply_msg_type The message type for any received reply. - * \param request_reply_error The error status from the attempt to send - * the request or retrieve the reply. - */ -static inline void -xs_reply_filter(uint32_t request_msg_type, - uint32_t reply_msg_type, int request_reply_error) -{ - /* - * The count of transactions drops if we attempted - * to end a transaction (even if that attempt fails - * in error), we receive a transaction end acknowledgement, - * or if our attempt to begin a transaction fails. - */ - if (request_msg_type == XS_TRANSACTION_END - || (request_reply_error == 0 && reply_msg_type == XS_TRANSACTION_END) - || (request_msg_type == XS_TRANSACTION_START - && (request_reply_error != 0 || reply_msg_type == XS_ERROR))) - sx_sunlock(&xs.suspend_mutex); - -} - #define xsd_error_count (sizeof(xsd_errors) / sizeof(xsd_errors[0])) /** @@ -843,7 +787,6 @@ int error; request_type = msg->type; - xs_request_filter(request_type); sx_xlock(&xs.request_mutex); if ((error = xs_write_store(msg, sizeof(*msg) + msg->len)) == 0) @@ -850,8 +793,6 @@ error = xs_read_reply(&msg->type, &msg->len, result); sx_xunlock(&xs.request_mutex); - xs_reply_filter(request_type, msg->type, error); - return (error); } @@ -887,8 +828,6 @@ for (i = 0; i < num_vecs; i++) msg.len += iovec[i].iov_len; - xs_request_filter(request_type); - sx_xlock(&xs.request_mutex); error = xs_write_store(&msg, sizeof(msg)); if (error) { @@ -908,7 +847,6 @@ error_lock_held: sx_xunlock(&xs.request_mutex); - xs_reply_filter(request_type, msg.type, error); if (error) return (error); @@ -1206,7 +1144,6 @@ mtx_init(&xs.reply_lock, "reply lock", NULL, MTX_DEF); sx_init(&xs.xenwatch_mutex, "xenwatch"); sx_init(&xs.request_mutex, "xenstore request"); - sx_init(&xs.suspend_mutex, "xenstore suspend"); mtx_init(&xs.registered_watches_lock, "watches", NULL, MTX_DEF); mtx_init(&xs.watch_events_lock, "watch events", NULL, MTX_DEF); @@ -1249,7 +1186,6 @@ if (error != 0) return (error); - sx_xlock(&xs.suspend_mutex); sx_xlock(&xs.request_mutex); return (0); @@ -1269,8 +1205,10 @@ sx_xunlock(&xs.request_mutex); /* - * No need for registered_watches_lock: the suspend_mutex - * is sufficient. + * NB: since xenstore childs have not been resumed yet, there's + * no need to hold any watch mutex. Having clients try to add or + * remove watches at this point (before xenstore is resumed) is + * clearly a violantion of the resume order. */ LIST_FOREACH(watch, &xs.registered_watches, list) { sprintf(token, "%lX", (long)watch); @@ -1277,8 +1215,6 @@ xs_watch(watch->node, token); } - sx_xunlock(&xs.suspend_mutex); - /* Resume child Xen devices. */ bus_generic_resume(dev); @@ -1631,8 +1567,6 @@ sprintf(token, "%lX", (long)watch); - sx_slock(&xs.suspend_mutex); - mtx_lock(&xs.registered_watches_lock); KASSERT(find_watch(token) == NULL, ("watch already registered")); LIST_INSERT_HEAD(&xs.registered_watches, watch, list); @@ -1650,8 +1584,6 @@ mtx_unlock(&xs.registered_watches_lock); } - sx_sunlock(&xs.suspend_mutex); - return (error); } @@ -1664,12 +1596,9 @@ sprintf(token, "%lX", (long)watch); - sx_slock(&xs.suspend_mutex); - mtx_lock(&xs.registered_watches_lock); if (find_watch(token) == NULL) { mtx_unlock(&xs.registered_watches_lock); - sx_sunlock(&xs.suspend_mutex); return; } LIST_REMOVE(watch, list); @@ -1680,8 +1609,6 @@ log(LOG_WARNING, "XENSTORE Failed to release watch %s: %i\n", watch->node, error); - sx_sunlock(&xs.suspend_mutex); - /* Cancel pending watch events. */ mtx_lock(&xs.watch_events_lock); TAILQ_FOREACH_SAFE(msg, &xs.watch_events, list, tmp) { --------------FC2B5AB8B9B6ED6E154A90A5 Content-Type: text/x-patch; name="0002-xenstore-don-t-wait-with-the-PCATCH-flag.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0002-xenstore-don-t-wait-with-the-PCATCH-flag.patch" >From c451da6a962f53b3892c1ece1c3e0473d5c93bc4 Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Thu, 15 Dec 2016 16:54:40 +0000 Subject: [PATCH 2/4] xenstore: don't wait with the PCATCH flag Due to the current synchronous xenstore implementation in FreeBSD, we cannot return from xs_read_reply without reading a reply, or else the ring gets out of sync and the next request will read the previous reply and crash due to the type mismatch. A proper solution involves making use of the req_id field in the message and allowing multiple in-flight messages at the same time on the ring. Sponsored by: Citrix Systems R&D --- sys/dev/xen/xenstore/xenstore.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sys/dev/xen/xenstore/xenstore.c b/sys/dev/xen/xenstore/xenstore.c index 14e4ebd..1c2e21f 100644 =================================================================== --- a/sys/dev/xen/xenstore/xenstore.c (revision 334101) +++ b/sys/dev/xen/xenstore/xenstore.c (working copy) @@ -798,8 +798,7 @@ mtx_lock(&xs.reply_lock); while (TAILQ_EMPTY(&xs.reply_list)) { - error = mtx_sleep(&xs.reply_list, &xs.reply_lock, - PCATCH, "xswait", hz/10); + error = mtx_sleep(&xs.reply_list, &xs.reply_lock, 0, "xswait", hz/10); if (error && error != EWOULDBLOCK) { mtx_unlock(&xs.reply_lock); return (error); --------------FC2B5AB8B9B6ED6E154A90A5 Content-Type: text/x-patch; name="0003-dev-xenstore-add-support-for-watches.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0003-dev-xenstore-add-support-for-watches.patch" >From debde7d62ebcb2ead12f3ff9708870dc329273d4 Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Thu, 15 Dec 2016 16:54:39 +0000 Subject: [PATCH 3/4] dev/xenstore: add support for watches Allow user-space applications to register watches using the xenstore device. This is needed in order to run toolstack operations on domains different than the one where xenstore is running (in which case the device is not used, since the connection to xenstore is done using a plain socket). Sponsored by: Citrix Systems R&D --- sys/dev/xen/xenstore/xenstore_dev.c | 267 +++++++++++++++++++++++++++++++++--- 1 file changed, 247 insertions(+), 20 deletions(-) diff --git a/sys/dev/xen/xenstore/xenstore_dev.c b/sys/dev/xen/xenstore/xenstore_dev.c index ce62140..18f86b8 100644 =================================================================== --- a/sys/dev/xen/xenstore/xenstore_dev.c (revision 334101) +++ b/sys/dev/xen/xenstore/xenstore_dev.c (working copy) @@ -44,6 +44,8 @@ #include #include #include +#include +#include #include @@ -56,10 +58,20 @@ struct xs_transaction handle; }; +struct xs_dev_watch { + LIST_ENTRY(xs_dev_watch) list; + struct xs_watch watch; + char *token; + struct xs_dev_data *user; +}; + struct xs_dev_data { /* In-progress transaction. */ - LIST_HEAD(xdd_list_head, xs_dev_transaction) transactions; + LIST_HEAD(, xs_dev_transaction) transactions; + /* Active watches. */ + LIST_HEAD(, xs_dev_watch) watches; + /* Partial request. */ unsigned int len; union { @@ -71,8 +83,136 @@ #define MASK_READ_IDX(idx) ((idx)&(PAGE_SIZE-1)) char read_buffer[PAGE_SIZE]; unsigned int read_cons, read_prod; + + /* Serializes writes to the read buffer. */ + struct mtx lock; + + /* Polling structure (for reads only ATM). */ + struct selinfo ev_rsel; }; +static void +xs_queue_reply(struct xs_dev_data *u, const char *data, unsigned int len) +{ + int i; + + for (i = 0; i < len; i++, u->read_prod++) + u->read_buffer[MASK_READ_IDX(u->read_prod)] = data[i]; + + KASSERT((u->read_prod - u->read_cons) <= sizeof(u->read_buffer), + ("xenstore reply too big")); + + wakeup(u); + selwakeup(&u->ev_rsel); +} + +static const char * +xs_dev_error_to_string(int error) +{ + int i; + + for (i = 0; i < nitems(xsd_errors); i++) + if (xsd_errors[i].errnum == error) + return (xsd_errors[i].errstring); + + return (NULL); +} + +static void +xs_dev_return_error(struct xs_dev_data *u, int error, int req_id, int tx_id) +{ + struct xsd_sockmsg msg; + const char *payload; + + msg.type = XS_ERROR; + msg.req_id = req_id; + msg.tx_id = tx_id; + payload = NULL; + + + payload = xs_dev_error_to_string(error); + if (payload == NULL) + payload = xs_dev_error_to_string(EINVAL); + KASSERT(payload != NULL, ("Unable to find string for EINVAL errno")); + + msg.len = strlen(payload) + 1; + + mtx_lock(&u->lock); + xs_queue_reply(u, (char *)&msg, sizeof(msg)); + xs_queue_reply(u, payload, msg.len); + mtx_unlock(&u->lock); +} + +static int +xs_dev_watch_message_parse_string(const char **p, const char *end, + const char **string_r) +{ + const char *nul = memchr(*p, 0, end - *p); + if (!nul) + return -EINVAL; + + *string_r = *p; + *p = nul+1; + + return 0; +} + +static int +xs_dev_watch_message_parse(const struct xsd_sockmsg *msg, const char **path_r, + const char **token_r) +{ + const char *begin = (const char*)msg; + const char *p = begin + sizeof(*msg); + const char *end = p + msg->len; + int error; + + KASSERT(p <= end, ("payload overflow")); + + error = xs_dev_watch_message_parse_string(&p, end, path_r); + if (error) + return error; + error = xs_dev_watch_message_parse_string(&p, end, token_r); + if (error) + return error; + + return 0; +} + +static struct xs_dev_watch * +xs_dev_find_watch(struct xs_dev_data *u, const char *token) +{ + struct xs_dev_watch *watch; + + LIST_FOREACH(watch, &u->watches, list) { + if (strcmp(watch->token, token) == 0) + return watch; + } + + return NULL; +} + +static void +xs_dev_watch_cb(struct xs_watch *watch, const char **vec, unsigned int len) +{ + struct xs_dev_watch *dwatch; + struct xsd_sockmsg msg; + char *payload; + + dwatch = (struct xs_dev_watch *)watch->callback_data; + msg.type = XS_WATCH_EVENT; + msg.req_id = msg.tx_id = 0; + msg.len = strlen(vec[XS_WATCH_PATH]) + strlen(dwatch->token) + 2; + + payload = malloc(msg.len, M_XENSTORE, M_WAITOK); + strcpy(payload, vec[XS_WATCH_PATH]); + strcpy(&payload[strlen(vec[XS_WATCH_PATH]) + 1], dwatch->token); + mtx_lock(&dwatch->user->lock); + xs_queue_reply(dwatch->user, (char *)&msg, sizeof(msg)); + xs_queue_reply(dwatch->user, payload, msg.len); + mtx_unlock(&dwatch->user->lock); + free(payload, M_XENSTORE); +} + static int xs_dev_read(struct cdev *dev, struct uio *uio, int ioflag) { @@ -101,27 +241,16 @@ return (0); } -static void -xs_queue_reply(struct xs_dev_data *u, char *data, unsigned int len) -{ - int i; - - for (i = 0; i < len; i++, u->read_prod++) - u->read_buffer[MASK_READ_IDX(u->read_prod)] = data[i]; - - KASSERT((u->read_prod - u->read_cons) <= sizeof(u->read_buffer), - ("xenstore reply too big")); - - wakeup(u); -} - static int xs_dev_write(struct cdev *dev, struct uio *uio, int ioflag) { int error; + const char *wpath, *wtoken; struct xs_dev_data *u; struct xs_dev_transaction *trans; + struct xs_dev_watch *watch; void *reply; + static const char *ok = "OK"; int len = uio->uio_resid; error = devfs_get_cdevpriv((void **)&u); @@ -168,35 +297,130 @@ LIST_REMOVE(trans, list); free(trans, M_XENSTORE); } + mtx_lock(&u->lock); xs_queue_reply(u, (char *)&u->u.msg, sizeof(u->u.msg)); xs_queue_reply(u, (char *)reply, u->u.msg.len); + mtx_unlock(&u->lock); free(reply, M_XENSTORE); } break; + case XS_WATCH: + u->u.msg.tx_id = 0; + error = xs_dev_watch_message_parse(&u->u.msg, &wpath, &wtoken); + if (error) + break; + if (xs_dev_find_watch(u, wtoken) != NULL) { + error = EINVAL; + break; + } + watch = malloc(sizeof(*watch), M_XENSTORE, M_WAITOK); + watch->watch.node = strdup(wpath, M_XENSTORE); + watch->watch.callback = xs_dev_watch_cb; + watch->watch.callback_data = (uintptr_t)watch; + watch->token = strdup(wtoken, M_XENSTORE); + watch->user = u; + + error = xs_register_watch(&watch->watch); + if (error != 0) { + free(watch->token, M_XENSTORE); + free(watch->watch.node, M_XENSTORE); + free(watch, M_XENSTORE); + break; + } + + LIST_INSERT_HEAD(&u->watches, watch, list); + u->u.msg.len = sizeof(ok); + mtx_lock(&u->lock); + xs_queue_reply(u, (char *)&u->u.msg, sizeof(u->u.msg)); + xs_queue_reply(u, ok, sizeof(ok)); + mtx_unlock(&u->lock); + break; + case XS_UNWATCH: + u->u.msg.tx_id = 0; + error = xs_dev_watch_message_parse(&u->u.msg, &wpath, &wtoken); + if (error) + break; + watch = xs_dev_find_watch(u, wtoken); + if (watch == NULL) { + error = EINVAL; + break; + } + + LIST_REMOVE(watch, list); + xs_unregister_watch(&watch->watch); + free(watch->watch.node, M_XENSTORE); + free(watch->token, M_XENSTORE); + free(watch, M_XENSTORE); + u->u.msg.len = sizeof(ok); + mtx_lock(&u->lock); + xs_queue_reply(u, (char *)&u->u.msg, sizeof(u->u.msg)); + xs_queue_reply(u, ok, sizeof(ok)); + mtx_unlock(&u->lock); + break; default: error = EINVAL; break; } - if (error == 0) - u->len = 0; + if (error != 0) + xs_dev_return_error(u, error, u->u.msg.req_id, u->u.msg.tx_id); - return (error); + /* Reset the write buffer. */ + u->len = 0; + + return (0); } +static int +xs_dev_poll(struct cdev *dev, int events, struct thread *td) +{ + struct xs_dev_data *u; + int error, mask; + + error = devfs_get_cdevpriv((void **)&u); + if (error != 0) + return (POLLERR); + + /* we can always write */ + mask = events & (POLLOUT | POLLWRNORM); + + if (events & (POLLIN | POLLRDNORM)) { + if (u->read_cons != u->read_prod) { + mask |= events & (POLLIN | POLLRDNORM); + } else { + /* Record that someone is waiting */ + selrecord(td, &u->ev_rsel); + } + } + + return (mask); +} + static void xs_dev_dtor(void *arg) { struct xs_dev_data *u = arg; - struct xs_dev_transaction *trans, *tmp; + struct xs_dev_transaction *trans, *tmpt; + struct xs_dev_watch *watch, *tmpw; - LIST_FOREACH_SAFE(trans, &u->transactions, list, tmp) { + seldrain(&u->ev_rsel); + + LIST_FOREACH_SAFE(trans, &u->transactions, list, tmpt) { xs_transaction_end(trans->handle, 1); LIST_REMOVE(trans, list); free(trans, M_XENSTORE); } + LIST_FOREACH_SAFE(watch, &u->watches, list, tmpw) { + LIST_REMOVE(watch, list); + xs_unregister_watch(&watch->watch); + free(watch->watch.node, M_XENSTORE); + free(watch->token, M_XENSTORE); + free(watch, M_XENSTORE); + } + mtx_destroy(&u->lock); + free(u, M_XENSTORE); } @@ -207,7 +431,9 @@ int error; u = malloc(sizeof(*u), M_XENSTORE, M_WAITOK|M_ZERO); + mtx_init(&u->lock, "xsdev_lock", NULL, MTX_DEF); LIST_INIT(&u->transactions); + LIST_INIT(&u->watches); error = devfs_set_cdevpriv(u, xs_dev_dtor); if (error != 0) free(u, M_XENSTORE); @@ -220,6 +446,7 @@ .d_read = xs_dev_read, .d_write = xs_dev_write, .d_open = xs_dev_open, + .d_poll = xs_dev_poll, .d_name = "xs_dev", }; --------------FC2B5AB8B9B6ED6E154A90A5 Content-Type: text/x-patch; name="0004-xenstore-dev-prevent-user-space-xenstore-device-from.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0004-xenstore-dev-prevent-user-space-xenstore-device-from.pa"; filename*1="tch" >From 751095963c026876152c8a9c2cbfd9ff76ae6329 Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Thu, 15 Dec 2016 16:54:40 +0000 Subject: [PATCH 4/4] xenstore/dev: prevent user-space xenstore device from hijacking transactions The user-space xenstore device is currently lacking a check to make sure that the caller is only using transaction ids currently assigned to it. This allows users of the xenstore device to hijack transactions not started by them, although the scope is limited to transactions started by the same domain. Sponsored by: Citrix Systems R&D --- sys/dev/xen/xenstore/xenstore_dev.c | 28 ++++++++++++++++++++++------ 1 file changed, 22 insertions(+), 6 deletions(-) diff --git a/sys/dev/xen/xenstore/xenstore_dev.c b/sys/dev/xen/xenstore/xenstore_dev.c index 18f86b8..de5d5e6 100644 =================================================================== --- a/sys/dev/xen/xenstore/xenstore_dev.c (revision 334101) +++ b/sys/dev/xen/xenstore/xenstore_dev.c (working copy) @@ -73,6 +73,18 @@ unsigned int read_cons, read_prod; }; +static struct xs_dev_transaction * +xs_dev_find_transaction(struct xs_dev_data *u, uint32_t tx_id) +{ + struct xs_dev_transaction *trans; + + LIST_FOREACH(trans, &u->transactions, list) + if (trans->handle.id == tx_id) + return trans; + + return NULL; +} + static int xs_dev_read(struct cdev *dev, struct uio *uio, int ioflag) { @@ -151,6 +163,12 @@ case XS_MKDIR: case XS_RM: case XS_SET_PERMS: + /* Check that this transaction id is not hijacked. */ + if (u->u.msg.tx_id != 0 && + xs_dev_find_transaction(u, u->u.msg.tx_id) == NULL) { + error = EINVAL; + break; + } error = xs_dev_request_and_reply(&u->u.msg, &reply); if (!error) { if (u->u.msg.type == XS_TRANSACTION_START) { @@ -159,12 +177,10 @@ trans->handle.id = strtoul(reply, NULL, 0); LIST_INSERT_HEAD(&u->transactions, trans, list); } else if (u->u.msg.type == XS_TRANSACTION_END) { - LIST_FOREACH(trans, &u->transactions, list) - if (trans->handle.id == u->u.msg.tx_id) - break; -#if 0 /* XXX does this mean the list is empty? */ - BUG_ON(&trans->list == &u->transactions); -#endif + trans = xs_dev_find_transaction(u, + u->u.msg.tx_id); + KASSERT(trans != NULL, + ("Unable to find transaction")); LIST_REMOVE(trans, list); free(trans, M_XENSTORE); } --------------FC2B5AB8B9B6ED6E154A90A5-- From owner-freebsd-xen@freebsd.org Thu May 24 11:26:13 2018 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D88E5EE8540 for ; Thu, 24 May 2018 11:26:12 +0000 (UTC) (envelope-from pratiy0100@gmail.com) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3CCAA84F27 for ; Thu, 24 May 2018 11:26:12 +0000 (UTC) (envelope-from pratiy0100@gmail.com) Received: by mail-wm0-x241.google.com with SMTP id f6-v6so4071304wmc.4 for ; Thu, 24 May 2018 04:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=8Zi6QcnvaMzANxr8ommRKuN3XJdiAnNCiE2bPkJ6TcI=; b=c+dwsz2Bh36z7gkzQybA+JzKatkdDWge5UIpXQNrXRSDGabi3cp2s6cVyWj0riwVei 9qT6A95RagI8VbP9xJ2NVRdyRbmtGtqwC4Ig6t2SmXewJu/p5C6eyOLS58poUBrxkMVe qq+PS9PnmlVNp5+I+5+btV5vQSYRQcwcoigkVzXc3VBQEypHLVcCRjZvcjb1GRcghCNf Nigu8c/NNCcMPHv+nYMSTfOiYEDjZSFAmTvUrk/Hk+/0QBP5SHC1Kc4ckYuLqIqjH7gF r9Zbi2cGMJ0dCLN65QiSJRBCTzTqPcoJrswTSxFzthW9QhTnNSmPpWzurRpfSoGQPU0z JSrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8Zi6QcnvaMzANxr8ommRKuN3XJdiAnNCiE2bPkJ6TcI=; b=bgDkn5gOaDowJ1sfHh3Mcq3V7Snp9cZ53hNa2hnX3nVN45daQbk8ye+QrZnQG38eoG voLtG7xNJ7ZnUiIbmdTonQNW9IfL5r7ijy81Ov9JhX1mxfV4WELUFImnH+US6nCtrr5W q9sz83WCwHafRrK4t0vw+KMgN+p06VY4JOoO1MXgsnZn6KL3Y1Nl1AxVrAfrQyQwsl/V uvmAcpl/Bu8vsfgE+we1lW+Mvo/jm15tLozjtVRJQFedxieGNSmp9GWuWCbzfQACraEn UShIZaHb/E3j9v3D3veoIXReJ4ODojGfKYXps+P8wle2TxOG2qew8q2i+GgIj/GI3sCu cGhA== X-Gm-Message-State: ALKqPwdnL5hmTI6OfbwmwCChbjG6j16/bmVRwL68+1yvMCbyl8v3vtKG vtYOWR7exL54gUFdttE2hH02FvLwhIVGdKVM5As= X-Google-Smtp-Source: AB8JxZp+ehWo30gfHGlX063oKTxo/KWHd59UIoM/RLhjZjFwWv7mZXIIeYXGXmUh+m2AI+6RIHmH2jxPmqwXED23vmM= X-Received: by 2002:aa7:d056:: with SMTP id n22-v6mr11649489edo.193.1527161171057; Thu, 24 May 2018 04:26:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:aa21:0:0:0:0:0 with HTTP; Thu, 24 May 2018 04:25:30 -0700 (PDT) In-Reply-To: <20180523151108.cxize3bblbpw3ewc@MBP-de-Roger.citrite.net> References: <20180519081030.qhzyjdrpwcekmcac@MacBook-Pro-de-Roger.local> <20180521090310.c46eexnwe4c7w62x@MacBook-Pro-de-Roger.local> <20180523081547.2vvthg42vmphvbex@MacBook-Pro-de-Roger.local> <20180523151108.cxize3bblbpw3ewc@MBP-de-Roger.citrite.net> From: Pratyush Yadav Date: Thu, 24 May 2018 16:55:30 +0530 Message-ID: Subject: Re: Xen kernel fails to boot, d0v1 triple fault looks like the cuplrit To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: FreeBSD-Xen Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 11:26:13 -0000 On Wed, May 23, 2018 at 8:41 PM, Roger Pau Monn=C3=A9 wrote: > On Wed, May 23, 2018 at 08:27:29PM +0530, Pratyush Yadav wrote: >> Hi, >> >> I think we have different pv.c files. For me, line 113 is: >> /* Xen init_ops implementation. */ >> >> The declarations of doublefault_stach, mce_stack, etc are in line 101. >> >> Similarly, line 329 for me is: >> { >> >> in function xen_pv_parse_symtab(void). The declarations your diff >> mentions in line 329 are in line 224. >> >> This is in sync with the official repository [0]. Maybe you have >> modifications that are not yet upstream? > > Sorry, I did indeed have other changes in pv.c. I'm appending the > patch on top of current HEAD. > >> Anyway, I manually made the changes. It still does not boot (I used >> make kernel -DKERNFAST, but I don't think that should make a >> difference). > > FWIW, I think the recommended way is KERNFAST=3D1. Thanks! > Can you paste the error? I think you should no longer get a triple > page fault in mp_machdep.c:307. > Yeah, the address does change. RIP now points to ffffffff80b52fbe. I ran addr2line on it and it points to ./machine/pcpu.h:231 I didn't write the full error because it is a lot of typing which takes time. Most of it is probably not useful information. If you do want the full error log, let me know and I'll type it out. One thing, I simply ran make kernel. Does that update kernel.debug, or do I have to do something else to update it? --=20 Regards, Pratyush Yadav From owner-freebsd-xen@freebsd.org Thu May 24 12:23:51 2018 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C024EEEA81 for ; Thu, 24 May 2018 12:23:51 +0000 (UTC) (envelope-from pratiy0100@gmail.com) Received: from mail-wm0-f68.google.com (mail-wm0-f68.google.com [74.125.82.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 119A1685C1 for ; Thu, 24 May 2018 12:23:50 +0000 (UTC) (envelope-from pratiy0100@gmail.com) Received: by mail-wm0-f68.google.com with SMTP id f8-v6so4696778wmc.4 for ; Thu, 24 May 2018 05:23:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5xL2QRWoja2EENjs6FRYcZ7cV7ZSyNzwT+mj4nsTPJA=; b=maIzcUhvtDJeM7IKs5N6xEGB2MMkLxkNhv3j9NmZoPWyWq3v9pWJyDcKjO2BKhQ7Sa R8G/kP1V4Jgjxym4SgOUheXZufEaMpXge3Lv+qYLx1qd+fh+NxgL8MItijTa4ulk5nrl uy7eKyEd8y6qgQdyE2UqaLS8r9LQOsTDMXLaaJs/bz/tftIeo9W+A9END53JCZ687Z0f Q6yVP3ODoZPHBBnL/Qq31kqtQEXUSygXgrQkH0081pW75cEMOsHBUOikGXuhDep7jMrr k7N9spwCk3q8GQNpRKcfPg+WrxKsL2VxHyryUMMgDtncqcOC1bMLCJQhTS+tME9/YRG0 b/NQ== X-Gm-Message-State: ALKqPwd5rMCWuY9nw7UzpDwRALQf4LY1dhqHys6fWAer2jPUU7FZ2Zr1 hT84j1JO4facV/QjyyugSD7wDe/Y X-Google-Smtp-Source: AB8JxZrwGA/ne3O8SkeT3Ailva/RAsYaN6m8OmoENm/nSnET+oLoUDU+L+V/8QiekjMVAB/JQlAKNA== X-Received: by 2002:a50:d649:: with SMTP id c9-v6mr3160352edj.16.1527164623710; Thu, 24 May 2018 05:23:43 -0700 (PDT) Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com. [74.125.82.54]) by smtp.gmail.com with ESMTPSA id m31-v6sm11713779edc.94.2018.05.24.05.23.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 May 2018 05:23:43 -0700 (PDT) Received: by mail-wm0-f54.google.com with SMTP id f6-v6so4543749wmc.4 for ; Thu, 24 May 2018 05:23:43 -0700 (PDT) X-Received: by 2002:a50:ad69:: with SMTP id z38-v6mr12008469edc.306.1527164623447; Thu, 24 May 2018 05:23:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:aa21:0:0:0:0:0 with HTTP; Thu, 24 May 2018 05:23:02 -0700 (PDT) From: Pratyush Yadav Date: Thu, 24 May 2018 17:53:02 +0530 X-Gmail-Original-Message-ID: Message-ID: Subject: Leftover code in gnttab.h? To: FreeBSD-Xen Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 12:23:51 -0000 Hi everyone, I was reading the Xen grant table code and I noticed that some code is wrapped in an #if 0. You can see it in sys/xen/gnttab.h:138. I have also attached the "commented out" part down below. Is it useful? Is it all right if I submit a patch that removes it? Regards, Pratyush Yadav #if 0 #include static inline void gnttab_set_map_op(struct gnttab_map_grant_ref *map, vm_paddr_t addr, uint32_t flags, grant_ref_t ref, domid_t domid) { if (flags & GNTMAP_contains_pte) map->host_addr = addr; else map->host_addr = vtophys(addr); map->flags = flags; map->ref = ref; map->dom = domid; } static inline void gnttab_set_unmap_op(struct gnttab_unmap_grant_ref *unmap, vm_paddr_t addr, uint32_t flags, grant_handle_t handle) { if (flags & GNTMAP_contains_pte) unmap->host_addr = addr; else unmap->host_addr = vtophys(addr); unmap->handle = handle; unmap->dev_bus_addr = 0; } static inline void gnttab_set_replace_op(struct gnttab_unmap_and_replace *unmap, vm_paddr_t addr, vm_paddr_t new_addr, grant_handle_t handle) { unmap->host_addr = vtophys(addr); unmap->new_addr = vtophys(new_addr); unmap->handle = handle; } #endif From owner-freebsd-xen@freebsd.org Thu May 24 14:06:54 2018 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDA91EF238A for ; Thu, 24 May 2018 14:06:54 +0000 (UTC) (envelope-from prvs=6753c1084=roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.eu.citrix.com [185.25.65.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.citrix.com", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1640E6D45C; Thu, 24 May 2018 14:06:53 +0000 (UTC) (envelope-from prvs=6753c1084=roger.pau@citrix.com) X-IronPort-AV: E=Sophos;i="5.49,436,1520899200"; d="scan'208";a="73654383" Date: Thu, 24 May 2018 16:06:36 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Pratyush Yadav CC: FreeBSD-Xen Subject: Re: Leftover code in gnttab.h? Message-ID: <20180524140636.7vz2gjshqow6efwe@MBP-de-Roger.citrite.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180323 X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 14:06:55 -0000 On Thu, May 24, 2018 at 05:53:02PM +0530, Pratyush Yadav wrote: > Hi everyone, > > I was reading the Xen grant table code and I noticed that some code is > wrapped in an #if 0. You can see it in sys/xen/gnttab.h:138. I have > also attached the "commented out" part down below. > > Is it useful? Is it all right if I submit a patch that removes it? This are leftovers from when the code was imported from Linux AFAICT. I guess the original committer thought that those functions would be implemented, so the prototypes where left in place. If you give me a patch to remove them I'm happy to commit it. Roger. From owner-freebsd-xen@freebsd.org Thu May 24 15:09:18 2018 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AAEB8EF4312 for ; Thu, 24 May 2018 15:09:18 +0000 (UTC) (envelope-from pratiy0100@gmail.com) Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CE8B70FC5 for ; Thu, 24 May 2018 15:09:17 +0000 (UTC) (envelope-from pratiy0100@gmail.com) Received: by mail-wm0-f67.google.com with SMTP id t11-v6so6134659wmt.0 for ; Thu, 24 May 2018 08:09:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wAn/tlHcnDnYjXoWtUv50bpusx+Fp3O3zNAMM39iTiw=; b=JArTQ7Y6H8MVKKgp7xvzIffkqRce71mQMiDVLMIxT76F8/a4Evi7kdAokmBVlxkoxk AoB1Kb3HsEDtDVVHeNlYMZIGr2NlDsn9406Qp+9qtta4vEoyVune7+DALP9uAg2RabhC 1DeUeRNIWw/U81EDZiGYDCQ63srKAQk5lUo5G80cYknOyVkyFJl6aNZhm9FuI1sLnrlV c+p6UcioMiSdtKMt6hyD2oAvt90D1QPvWsIEHMECf5qiLz4At2AjBAX0dCcDMuaZtYSZ rwwtRQo7vCUL10n/qzHkbLL3kmpyUnskRH++nbWBgNqxynDCkeXRDK7g3z+WRX5LL3EZ x1Sg== X-Gm-Message-State: ALKqPweRuUoy4iwsxIKDw92V7Qzv6RDGGucMJTz2VN8LN/JBVQKOh6lF sFRkuNjZE4TVnbOvRtfoM+U8O3BAPIs= X-Google-Smtp-Source: AB8JxZpb1QiVjKmJ4aToQotQNgmq01KHK1GDCEiJyLd2aWjBP+wZTT17CLpMBv/RCyWw0wmNk2WNmQ== X-Received: by 2002:a50:a985:: with SMTP id n5-v6mr12706906edc.112.1527174551466; Thu, 24 May 2018 08:09:11 -0700 (PDT) Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com. [74.125.82.52]) by smtp.gmail.com with ESMTPSA id e6-v6sm11345657eds.20.2018.05.24.08.09.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 May 2018 08:09:11 -0700 (PDT) Received: by mail-wm0-f52.google.com with SMTP id j4-v6so6135626wme.1 for ; Thu, 24 May 2018 08:09:11 -0700 (PDT) X-Received: by 2002:a50:8561:: with SMTP id 88-v6mr1698921edr.119.1527174550872; Thu, 24 May 2018 08:09:10 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:aa21:0:0:0:0:0 with HTTP; Thu, 24 May 2018 08:08:30 -0700 (PDT) In-Reply-To: <20180524140636.7vz2gjshqow6efwe@MBP-de-Roger.citrite.net> References: <20180524140636.7vz2gjshqow6efwe@MBP-de-Roger.citrite.net> From: Pratyush Yadav Date: Thu, 24 May 2018 20:38:30 +0530 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Leftover code in gnttab.h? To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: FreeBSD-Xen Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 15:09:18 -0000 Hi, On Thu, May 24, 2018 at 7:36 PM, Roger Pau Monn=C3=A9 wrote: > On Thu, May 24, 2018 at 05:53:02PM +0530, Pratyush Yadav wrote: >> Hi everyone, >> >> I was reading the Xen grant table code and I noticed that some code is >> wrapped in an #if 0. You can see it in sys/xen/gnttab.h:138. I have >> also attached the "commented out" part down below. >> >> Is it useful? Is it all right if I submit a patch that removes it? > > This are leftovers from when the code was imported from Linux AFAICT. > I guess the original committer thought that those functions would be > implemented, so the prototypes where left in place. > > If you give me a patch to remove them I'm happy to commit it. How should I send you the patch? Should I send it through reviews.freebsd.org, GitHub pull request or just paste the patch in the email? --=20 Regards, Pratyush Yadav From owner-freebsd-xen@freebsd.org Thu May 24 15:13:01 2018 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9307BEF44F8 for ; Thu, 24 May 2018 15:13:01 +0000 (UTC) (envelope-from prvs=6753c1084=roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.eu.citrix.com [185.25.65.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.citrix.com", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DCEBC71453; Thu, 24 May 2018 15:13:00 +0000 (UTC) (envelope-from prvs=6753c1084=roger.pau@citrix.com) X-IronPort-AV: E=Sophos;i="5.49,436,1520899200"; d="scan'208";a="73660476" Date: Thu, 24 May 2018 17:12:01 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Pratyush Yadav CC: FreeBSD-Xen Subject: Re: Leftover code in gnttab.h? Message-ID: <20180524151201.gtpey5wifislq3z2@MBP-de-Roger.citrite.net> References: <20180524140636.7vz2gjshqow6efwe@MBP-de-Roger.citrite.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180323 X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 15:13:01 -0000 On Thu, May 24, 2018 at 08:38:30PM +0530, Pratyush Yadav wrote: > Hi, > > On Thu, May 24, 2018 at 7:36 PM, Roger Pau Monné wrote: > > On Thu, May 24, 2018 at 05:53:02PM +0530, Pratyush Yadav wrote: > >> Hi everyone, > >> > >> I was reading the Xen grant table code and I noticed that some code is > >> wrapped in an #if 0. You can see it in sys/xen/gnttab.h:138. I have > >> also attached the "commented out" part down below. > >> > >> Is it useful? Is it all right if I submit a patch that removes it? > > > > This are leftovers from when the code was imported from Linux AFAICT. > > I guess the original committer thought that those functions would be > > implemented, so the prototypes where left in place. > > > > If you give me a patch to remove them I'm happy to commit it. > > How should I send you the patch? Should I send it through > reviews.freebsd.org, GitHub pull request or just paste the patch in > the email? Let's use reviews.freebsd.org, so that you can get used to it. Roger. From owner-freebsd-xen@freebsd.org Thu May 24 15:24:20 2018 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 072F5EF4B70 for ; Thu, 24 May 2018 15:24:20 +0000 (UTC) (envelope-from pratiy0100@gmail.com) Received: from mail-wm0-f65.google.com (mail-wm0-f65.google.com [74.125.82.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 77F7B72456 for ; Thu, 24 May 2018 15:24:19 +0000 (UTC) (envelope-from pratiy0100@gmail.com) Received: by mail-wm0-f65.google.com with SMTP id j4-v6so6276403wme.1 for ; Thu, 24 May 2018 08:24:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4duavV0QNy1essYvsyrMREe9E/luFG1Kcnbvik2hV5s=; b=XwwQoBIH/FG7ylVxaDvGe2e+EKq6X3Ij07pjuC95Cj9glKRSyoL3uBi0HekyRurJob RQmUWvpxKX9sG4UwZUXcxjfXcyJifyxaqCdqcT4GyCBVhU/4do+3pA/NsQ9oZ6Qr3lV9 Zi3cjyMLPmtM7YZENKoZ9bGjv7djm8q5VXEYvLaAd3AKwi/tFGwk8iDVm9UAcBkNFcko us08SR2j5gCM3N7q/wk22ztb4hj51mMSsKLc+ijYnsmXx/zhZAUzltSoFrPO8t3CG+a+ e84Y4B3ZpbBUOl4mFC2XoNlmthLNf1hivNBQgZ8lkuoNemHuK3HhbJRIREqjChymzHnu bX6g== X-Gm-Message-State: ALKqPweST0v8Io297n3P4mfEOGrsXoLHocsAxyotBWCSzcYCUkS1z3r8 D1ylqESB+kVr2A7t0dmAGMfaLpfyLxs= X-Google-Smtp-Source: AB8JxZpq48YJDHs3ihn3cMK0asSOwst1Qu1R1fxyieOfN4GHaBXkWQ6HTZvXh5ObmWEH7MBx5d3ALg== X-Received: by 2002:a50:d6d9:: with SMTP id l25-v6mr12812019edj.259.1527175457978; Thu, 24 May 2018 08:24:17 -0700 (PDT) Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com. [74.125.82.44]) by smtp.gmail.com with ESMTPSA id 49-v6sm12198644edz.87.2018.05.24.08.24.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 May 2018 08:24:17 -0700 (PDT) Received: by mail-wm0-f44.google.com with SMTP id a67-v6so6213505wmf.3 for ; Thu, 24 May 2018 08:24:17 -0700 (PDT) X-Received: by 2002:a50:fd12:: with SMTP id i18-v6mr12883702eds.158.1527175457714; Thu, 24 May 2018 08:24:17 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:aa21:0:0:0:0:0 with HTTP; Thu, 24 May 2018 08:23:37 -0700 (PDT) In-Reply-To: <20180524151201.gtpey5wifislq3z2@MBP-de-Roger.citrite.net> References: <20180524140636.7vz2gjshqow6efwe@MBP-de-Roger.citrite.net> <20180524151201.gtpey5wifislq3z2@MBP-de-Roger.citrite.net> From: Pratyush Yadav Date: Thu, 24 May 2018 20:53:37 +0530 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Leftover code in gnttab.h? To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: FreeBSD-Xen Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 15:24:20 -0000 On Thu, May 24, 2018 at 8:42 PM, Roger Pau Monn=C3=A9 wrote: > On Thu, May 24, 2018 at 08:38:30PM +0530, Pratyush Yadav wrote: >> Hi, >> >> On Thu, May 24, 2018 at 7:36 PM, Roger Pau Monn=C3=A9 wrote: >> > On Thu, May 24, 2018 at 05:53:02PM +0530, Pratyush Yadav wrote: >> >> Hi everyone, >> >> >> >> I was reading the Xen grant table code and I noticed that some code i= s >> >> wrapped in an #if 0. You can see it in sys/xen/gnttab.h:138. I have >> >> also attached the "commented out" part down below. >> >> >> >> Is it useful? Is it all right if I submit a patch that removes it? >> > >> > This are leftovers from when the code was imported from Linux AFAICT. >> > I guess the original committer thought that those functions would be >> > implemented, so the prototypes where left in place. >> > >> > If you give me a patch to remove them I'm happy to commit it. >> >> How should I send you the patch? Should I send it through >> reviews.freebsd.org, GitHub pull request or just paste the patch in >> the email? > > Let's use reviews.freebsd.org, so that you can get used to it. In case you didn't get the notificaton: https://reviews.freebsd.org/D15553 --=20 Regards, Pratyush Yadav