Re: [Xen-devel] [PATCH v9 15/19] xen: create a Xen nexus to use in PV/PVH
On 07/01/14 15:27, Julien Grall wrote: On 01/07/2014 08:29 AM, Roger Pau Monné wrote: On 06/01/14 12:33, Julien Grall wrote: On 01/06/2014 09:35 AM, Roger Pau Monné wrote: On 05/01/14 22:55, Julien Grall wrote: On 01/02/2014 03:43 PM, Roger Pau Monne wrote: Introduce a Xen specific nexus that is going to be in charge for attaching Xen specific devices. Now that we have a xenpv bus, do we really need a specific nexus for Xen? We should be able to use the identify callback of xenpv to create the bus. The other part of this patch can be merged in the patch #14 Introduce xenpv bus and a dummy pvcpu device. On x86 at least we need the Xen specific nexus, or we will fall back to use the legacy nexus which is not what we really want. Oh right, in any case can we use the identify callback of xenpv to add the bus? AFAICT this kind of bus devices don't have a identify routine, and they are usually added manually from the specific nexus, see acpi or legacy. Could you add the device on ARM when you detect that you are running as a Xen guest, or in the generic ARM nexus if Xen is detected? Is there any reason to not add identify callback? If it's possible, I would like to avoid as much as possible #ifdef XENHVM in ARM code. Maybe the x86 world is really different from the ARM world in how nexus works, but I rather prefer to have a #ifdef XENHVM and a BUS_ADD_CHILD that attaches the xenpv bus in the generic ARM nexus rather than having something that completely diverges from what buses usually do in FreeBSD. It's going to be much more difficult to track in case of bugs, and it's not what people expects, but that's just my opinion. I can certainly add the identify routine if there's an agreement that it's the best way to deal with it. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: [Xen-devel] [PATCH v9 15/19] xen: create a Xen nexus to use in PV/PVH
On 01/09/14 11:30, Roger Pau Monné wrote: On 07/01/14 15:27, Julien Grall wrote: On 01/07/2014 08:29 AM, Roger Pau Monné wrote: On 06/01/14 12:33, Julien Grall wrote: On 01/06/2014 09:35 AM, Roger Pau Monné wrote: On 05/01/14 22:55, Julien Grall wrote: On 01/02/2014 03:43 PM, Roger Pau Monne wrote: Introduce a Xen specific nexus that is going to be in charge for attaching Xen specific devices. Now that we have a xenpv bus, do we really need a specific nexus for Xen? We should be able to use the identify callback of xenpv to create the bus. The other part of this patch can be merged in the patch #14 Introduce xenpv bus and a dummy pvcpu device. On x86 at least we need the Xen specific nexus, or we will fall back to use the legacy nexus which is not what we really want. Oh right, in any case can we use the identify callback of xenpv to add the bus? AFAICT this kind of bus devices don't have a identify routine, and they are usually added manually from the specific nexus, see acpi or legacy. Could you add the device on ARM when you detect that you are running as a Xen guest, or in the generic ARM nexus if Xen is detected? Is there any reason to not add identify callback? If it's possible, I would like to avoid as much as possible #ifdef XENHVM in ARM code. Maybe the x86 world is really different from the ARM world in how nexus works, but I rather prefer to have a #ifdef XENHVM and a BUS_ADD_CHILD that attaches the xenpv bus in the generic ARM nexus rather than having something that completely diverges from what buses usually do in FreeBSD. It's going to be much more difficult to track in case of bugs, and it's not what people expects, but that's just my opinion. I can certainly add the identify routine if there's an agreement that it's the best way to deal with it. Roger. ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Attaching sub-devices to nexus using device_identify() is the usual way to do this kind of thing. Note that if you do this, your device_probe() routine should return BUS_PROBE_NOWILDCARD to deal with platforms (ARM, MIPS, PowerPC, sparc64) with real autoconfigured devices hanging directly from nexus. -Nathan ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: [Xen-devel] [PATCH v9 15/19] xen: create a Xen nexus to use in PV/PVH
On 01/06/2014 09:35 AM, Roger Pau Monné wrote: On 05/01/14 22:55, Julien Grall wrote: On 01/02/2014 03:43 PM, Roger Pau Monne wrote: Introduce a Xen specific nexus that is going to be in charge for attaching Xen specific devices. Now that we have a xenpv bus, do we really need a specific nexus for Xen? We should be able to use the identify callback of xenpv to create the bus. The other part of this patch can be merged in the patch #14 Introduce xenpv bus and a dummy pvcpu device. On x86 at least we need the Xen specific nexus, or we will fall back to use the legacy nexus which is not what we really want. Oh right, in any case can we use the identify callback of xenpv to add the bus? With this solution xenpv can add itself no matter FreeBSD use the generic nexus or the nexus Xen, of course with a check if we are running on Xen :). For instance, on ARM side I don't plan to have a specific Xen nexus. Cheers, -- Julien Grall ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: [Xen-devel] [PATCH v9 15/19] xen: create a Xen nexus to use in PV/PVH
On 01/02/2014 03:43 PM, Roger Pau Monne wrote: Introduce a Xen specific nexus that is going to be in charge for attaching Xen specific devices. Now that we have a xenpv bus, do we really need a specific nexus for Xen? We should be able to use the identify callback of xenpv to create the bus. The other part of this patch can be merged in the patch #14 Introduce xenpv bus and a dummy pvcpu device. -- Julien Grall ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
[PATCH v9 15/19] xen: create a Xen nexus to use in PV/PVH
Introduce a Xen specific nexus that is going to be in charge for
attaching Xen specific devices.
---
sys/conf/files.amd64 |1 +
sys/conf/files.i386 |1 +
sys/dev/xen/console/console.c |2 +-
sys/dev/xen/timer/timer.c |4 +-
sys/dev/xen/xenpci/xenpci.c |4 ++
sys/x86/xen/xen_nexus.c | 82 +
sys/x86/xen/xenpv.c |1 +
sys/xen/xenstore/xenstore.c |6 +--
8 files changed, 93 insertions(+), 8 deletions(-)
create mode 100644 sys/x86/xen/xen_nexus.c
diff --git a/sys/conf/files.amd64 b/sys/conf/files.amd64
index d7c98cc..f378983 100644
--- a/sys/conf/files.amd64
+++ b/sys/conf/files.amd64
@@ -571,3 +571,4 @@ x86/xen/xen_intr.c optionalxen | xenhvm
x86/xen/pv.c optionalxenhvm
x86/xen/pvcpu_enum.c optionalxenhvm
x86/xen/xenpv.coptionalxenhvm
+x86/xen/xen_nexus.coptionalxenhvm
diff --git a/sys/conf/files.i386 b/sys/conf/files.i386
index 81142e3..02887a33 100644
--- a/sys/conf/files.i386
+++ b/sys/conf/files.i386
@@ -604,3 +604,4 @@ x86/x86/delay.c standard
x86/xen/hvm.c optional xenhvm
x86/xen/xen_intr.c optional xen | xenhvm
x86/xen/xenpv.coptional xen | xenhvm
+x86/xen/xen_nexus.coptional xen | xenhvm
diff --git a/sys/dev/xen/console/console.c b/sys/dev/xen/console/console.c
index 899dffc..91538fe 100644
--- a/sys/dev/xen/console/console.c
+++ b/sys/dev/xen/console/console.c
@@ -462,4 +462,4 @@ xcons_force_flush(void)
}
}
-DRIVER_MODULE(xc, nexus, xc_driver, xc_devclass, 0, 0);
+DRIVER_MODULE(xc, xenpv, xc_driver, xc_devclass, 0, 0);
diff --git a/sys/dev/xen/timer/timer.c b/sys/dev/xen/timer/timer.c
index 96372ab..f16f5a5 100644
--- a/sys/dev/xen/timer/timer.c
+++ b/sys/dev/xen/timer/timer.c
@@ -636,5 +636,5 @@ static driver_t xentimer_driver = {
sizeof(struct xentimer_softc),
};
-DRIVER_MODULE(xentimer, nexus, xentimer_driver, xentimer_devclass, 0, 0);
-MODULE_DEPEND(xentimer, nexus, 1, 1, 1);
+DRIVER_MODULE(xentimer, xenpv, xentimer_driver, xentimer_devclass, 0, 0);
+MODULE_DEPEND(xentimer, xenpv, 1, 1, 1);
diff --git a/sys/dev/xen/xenpci/xenpci.c b/sys/dev/xen/xenpci/xenpci.c
index dd2ad92..a27b54f 100644
--- a/sys/dev/xen/xenpci/xenpci.c
+++ b/sys/dev/xen/xenpci/xenpci.c
@@ -270,6 +270,10 @@ xenpci_attach(device_t dev)
goto errexit;
}
+ /* Add the xenpv device so top level Xen devices can attach */
+ if (BUS_ADD_CHILD(dev, 0, xenpv, 0) == NULL)
+ panic(xenpci: unable to add xenpv device);
+
return (bus_generic_attach(dev));
errexit:
diff --git a/sys/x86/xen/xen_nexus.c b/sys/x86/xen/xen_nexus.c
new file mode 100644
index 000..d34e333
--- /dev/null
+++ b/sys/x86/xen/xen_nexus.c
@@ -0,0 +1,82 @@
+/*
+ * Copyright (c) 2013 Roger Pau Monné roger@citrix.com
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include sys/cdefs.h
+__FBSDID($FreeBSD$);
+
+#include sys/param.h
+#include sys/bus.h
+#include sys/kernel.h
+#include sys/module.h
+#include sys/sysctl.h
+#include sys/systm.h
+#include sys/smp.h
+
+#include machine/nexusvar.h
+
+#include xen/xen-os.h
+
+/*
+ * Xen nexus(4) driver.
+ */
+static int
+nexus_xen_probe(device_t dev)
+{
+ if (!xen_pv_domain())
+ return (ENXIO);
+
+ return (BUS_PROBE_DEFAULT);
+}
+
+static int
+nexus_xen_attach(device_t dev)
+{
+
+ nexus_init_resources();
+ bus_generic_probe(dev);
+
+ /*
+* Explicitly add the xenpv device here. Other top level
+* Xen
