Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 May 2018 20:34:54 -0600
From:      Nathan Friess <nathan.friess@gmail.com>
To:        =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <royger@FreeBSD.org>, Kai Otto <kai_otto@duckster.net>
Cc:        freebsd-xen@freebsd.org
Subject:   Re: Linux domU only works with xen_platform_pci=0 ?
Message-ID:  <6c0e1f5a-3e7d-054e-298c-5ec3d97e6141@gmail.com>
In-Reply-To: <20180514130445.ahqk5ol3kdhriqju@MacBook-Pro-de-Roger.local>
References:  <a5a066b7-625f-d18f-6ea6-663256c09e59@duckster.net> <20180513151649.4ls73myegkhm3cep@MacBook-Pro-de-Roger.local> <0749df4b-1614-dcdf-1bf2-1bbad1ae5743@duckster.net> <20180514130445.ahqk5ol3kdhriqju@MacBook-Pro-de-Roger.local>

next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------E874B936718ADF8811C4B06C
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 2018-05-14 07:04 AM, Roger Pau Monné wrote:
> On Sun, May 13, 2018 at 07:33:03PM +0200, Kai Otto wrote:
>> On 13/05/18 17:16, Roger Pau Monné wrote:
>>> On Sun, May 13, 2018 at 03:51:36PM +0200, Kai Otto wrote:
>>>> Hello,
>>>>
>>>> I'm trying to set up a FreeBSD 11.1 system as Xen virtualization host.
>>>> Following a combination of handbook [1] and wiki [2], I was able to get
>>>> get a FreeBSD dom0 in PVH mode, and FreeBSD domU in HVM mode running,
>>>> including installation to disk and networking.
>>>>
>>>> It seemed to me as if the switch 'xen_platform_pci' doesn't have an
>>>> effect on FreeBSD domU's, as I see e.g. a xenpci0 and xbd0 in dmesg no
>>>> matter if I set it to 1 or 0.
>>>>
>>>> Do I understand it correctly, that this switch makes the difference
>>>> between HVM and PVHVM mode?
>>>> According to xl.cfg(5), it 'enables a guest Operating System [...] to
>>>> make use of paravirtualization features such as disk and network devices'.
>>>>
>>>>
>>>> Afterwards, I tried to create a Linux domU. Both Centos 7 and Alpine
>>>> Linux only detected the harddisk with xen_platform_pci=0.
>>>>
>>>> For Alpine Linux, with xen_platform_pci=1, I get the following messages
>>>> on the console:
>>>>
>>>> vbd vbd-5632: 19 xenbus_dev_probe on device/vbd/5632
>>> That's ENODEV IIRC, I think there's something wrong with FreeBSD disk
>>> backend.
>>>
>>>> vbd vbd-5632: failed to write error node for device/vbd/5632 (19
>>>> xenbus_dev_probe on device/vbd/5632)
>>>>
>>>> After waiting for a couple minutes it boots, but doesn't detect the disk.

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.

Nathan

--------------E874B936718ADF8811C4B06C
Content-Type: text/x-patch;
 name="missed-notifications.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="missed-notifications.patch"

Index: sys/dev/xen/blkback/blkback.c
===================================================================
--- sys/dev/xen/blkback/blkback.c	(revision 321598)
+++ sys/dev/xen/blkback/blkback.c	(working copy)
@@ -3692,6 +3692,11 @@
 
 	/* Tell the front end that we are ready to connect. */
 	xenbus_set_state(dev, XenbusStateInitialised);
+
+	/* The front end may have finished first, so we should proceed as well. */
+	if (xenbus_get_otherend_state(xbb->dev) == XenbusStateInitialised) {
+		xbb_connect(xbb);
+	}
 }
 
 /**
@@ -3769,6 +3774,14 @@
 		return (error);
 	}
 
+	/*
+	 * We may need to wait for Linux frontend to become ready
+	 * so it will not miss us going into InitWait.
+	 */
+	if (xenbus_get_otherend_state(xbb->dev) != XenbusStateInitialising) {
+		pause("xbb_attach", 100);
+	}
+
 	/* Tell the toolstack blkback has attached. */
 	xenbus_set_state(dev, XenbusStateInitWait);
 

--------------E874B936718ADF8811C4B06C--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6c0e1f5a-3e7d-054e-298c-5ec3d97e6141>