From owner-freebsd-xen@freebsd.org Sat May 19 08:02:59 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 283FEEF2E47 for ; Sat, 19 May 2018 08:02:59 +0000 (UTC) (envelope-from royger@FreeBSD.org) Received: from smtp.freebsd.org (unknown [IPv6:2610:1c1:1:606c::24b:4]) (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 C35A08509E; Sat, 19 May 2018 08:02:58 +0000 (UTC) (envelope-from royger@FreeBSD.org) Received: from localhost (87.red-83-59-60.dynamicip.rima-tde.net [83.59.60.87]) (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 2D3B621F5F; Sat, 19 May 2018 08:02:57 +0000 (UTC) (envelope-from royger@FreeBSD.org) Date: Sat, 19 May 2018 10:02:50 +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: <20180519080250.67fl66gqbew7xfzp@MacBook-Pro-de-Roger.local> 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> 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-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: Sat, 19 May 2018 08:02:59 -0000 On Thu, May 17, 2018 at 06:10:15PM -0600, Nathan Friess wrote: > On 2018-05-15 02:08 AM, Roger Pau Monné wrote: > > On Mon, May 14, 2018 at 08:34:54PM -0600, Nathan Friess wrote: > > > > > > I had similar issues with Linux domUs being unable to detect their disks > > > when FreeBSD 11.1-RELEASE is the backend: > > > > > > https://lists.freebsd.org/pipermail/freebsd-xen/2016-December/002924.html > > > > > > > > > What seems to be happening is that on my system the frontend and backend may > > > go from state InitWait to Initialised in different orders and so either end > > > may end up getting stuck waiting for the other side to change state when the > > > other side already has done so. > > > > > > I have been running with the attached patch since my last message above and > > > Linux domUs have been working perfectly since then. I realize that the call > > > to pause() is not the correct solution but it demonstrates that some fine > > > tuning of how the states are handled will help. > > > > Can you please give a try to the patch at: > > > > https://lists.freebsd.org/pipermail/freebsd-xen/2018-May/003132.html > > > > I think this is the proper way to solve the issue, and I would like to > > commit it ASAP in order to MFC it to stable-11 before 11.2 is > > released, but it could benefit from some more testing. > > > > Thanks, Roger. > > > > > 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.