Re: [PATCH v10 14/20] xen: introduce xenpv bus and a dummy pvcpu device
On 01/14/2014 04:20 PM, Roger Pau Monné wrote:
> On 14/01/14 17:14, Julien Grall wrote:
>> On 01/14/2014 04:08 PM, Roger Pau Monné wrote:
>>> On 14/01/14 16:41, Julien Grall wrote:
On 01/14/2014 02:59 PM, Roger Pau Monne wrote:
> +static int
> +xenpv_attach(device_t dev)
> +{
> + device_t child;
> +
> + if (xen_hvm_domain()) {
> + device_t xenpci;
> + devclass_t dc;
> +
> + /* Make sure xenpci has been attached */
> + dc = devclass_find("xenpci");
> + if (dc == NULL)
> + panic("unable to find xenpci devclass");
> +
> + xenpci = devclass_get_device(dc, 0);
> + if (xenpci == NULL)
> + panic("unable to find xenpci device");
> +
> + if (!device_is_attached(xenpci))
> + panic("trying to attach xenpv before xenpci");
> + }
Can you use the identify method to add the xenpci device?
>>>
>>> I don't think so, xenpci is a pci device, it is detected and plugged by
>>> the pci bus code.
>>
>> Oups, I though you are trying to add the device. In this case, the check
>> seems pointless. In which case the xenpci couldn't exist?
>
> It's just a "belt and suspenders", if we attach the xenpv bus without
> xenpci being attached first a bunch of things are going to fail, I
> though it might be best to print a clear error message about what went
> wrong in order to help debug it.
I only see one place which could failed, and we are already protected.
It's when we are trying to allocate space from grant-table via
xenpci_alloc_space.
I think this error should be enough to understand the problem. At the
same time, it's the same things with xenstore. If grant-table
initialization has failed, an error message is just printed and FreeBSD
will likely failed later when it will try to initialized the PV disk.
--
Julien Grall
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH v10 14/20] xen: introduce xenpv bus and a dummy pvcpu device
On 01/14/2014 04:08 PM, Roger Pau Monné wrote:
> On 14/01/14 16:41, Julien Grall wrote:
>> On 01/14/2014 02:59 PM, Roger Pau Monne wrote:
>>> +static int
>>> +xenpv_attach(device_t dev)
>>> +{
>>> + device_t child;
>>> +
>>> + if (xen_hvm_domain()) {
>>> + device_t xenpci;
>>> + devclass_t dc;
>>> +
>>> + /* Make sure xenpci has been attached */
>>> + dc = devclass_find("xenpci");
>>> + if (dc == NULL)
>>> + panic("unable to find xenpci devclass");
>>> +
>>> + xenpci = devclass_get_device(dc, 0);
>>> + if (xenpci == NULL)
>>> + panic("unable to find xenpci device");
>>> +
>>> + if (!device_is_attached(xenpci))
>>> + panic("trying to attach xenpv before xenpci");
>>> + }
>>
>> Can you use the identify method to add the xenpci device?
>
> I don't think so, xenpci is a pci device, it is detected and plugged by
> the pci bus code.
Oups, I though you are trying to add the device. In this case, the check
seems pointless. In which case the xenpci couldn't exist?
--
Julien Grall
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH v10 14/20] xen: introduce xenpv bus and a dummy pvcpu device
On 14/01/14 17:14, Julien Grall wrote:
> On 01/14/2014 04:08 PM, Roger Pau Monné wrote:
>> On 14/01/14 16:41, Julien Grall wrote:
>>> On 01/14/2014 02:59 PM, Roger Pau Monne wrote:
+static int
+xenpv_attach(device_t dev)
+{
+ device_t child;
+
+ if (xen_hvm_domain()) {
+ device_t xenpci;
+ devclass_t dc;
+
+ /* Make sure xenpci has been attached */
+ dc = devclass_find("xenpci");
+ if (dc == NULL)
+ panic("unable to find xenpci devclass");
+
+ xenpci = devclass_get_device(dc, 0);
+ if (xenpci == NULL)
+ panic("unable to find xenpci device");
+
+ if (!device_is_attached(xenpci))
+ panic("trying to attach xenpv before xenpci");
+ }
>>>
>>> Can you use the identify method to add the xenpci device?
>>
>> I don't think so, xenpci is a pci device, it is detected and plugged by
>> the pci bus code.
>
> Oups, I though you are trying to add the device. In this case, the check
> seems pointless. In which case the xenpci couldn't exist?
It's just a "belt and suspenders", if we attach the xenpv bus without
xenpci being attached first a bunch of things are going to fail, I
though it might be best to print a clear error message about what went
wrong in order to help debug it.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH v10 14/20] xen: introduce xenpv bus and a dummy pvcpu device
On 14/01/14 16:41, Julien Grall wrote:
> On 01/14/2014 02:59 PM, Roger Pau Monne wrote:
>> +static int
>> +xenpv_attach(device_t dev)
>> +{
>> +device_t child;
>> +
>> +if (xen_hvm_domain()) {
>> +device_t xenpci;
>> +devclass_t dc;
>> +
>> +/* Make sure xenpci has been attached */
>> +dc = devclass_find("xenpci");
>> +if (dc == NULL)
>> +panic("unable to find xenpci devclass");
>> +
>> +xenpci = devclass_get_device(dc, 0);
>> +if (xenpci == NULL)
>> +panic("unable to find xenpci device");
>> +
>> +if (!device_is_attached(xenpci))
>> +panic("trying to attach xenpv before xenpci");
>> +}
>
> Can you use the identify method to add the xenpci device?
I don't think so, xenpci is a pci device, it is detected and plugged by
the pci bus code.
> As I said earlier, I will reuse this code for ARM guest and this device
> is not used on this architecture.
You could move this chunk of code (the check for xenpci) to a static
inline function and make it a noop for ARM.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH v10 14/20] xen: introduce xenpv bus and a dummy pvcpu device
On 01/14/2014 02:59 PM, Roger Pau Monne wrote:
> +static int
> +xenpv_attach(device_t dev)
> +{
> + device_t child;
> +
> + if (xen_hvm_domain()) {
> + device_t xenpci;
> + devclass_t dc;
> +
> + /* Make sure xenpci has been attached */
> + dc = devclass_find("xenpci");
> + if (dc == NULL)
> + panic("unable to find xenpci devclass");
> +
> + xenpci = devclass_get_device(dc, 0);
> + if (xenpci == NULL)
> + panic("unable to find xenpci device");
> +
> + if (!device_is_attached(xenpci))
> + panic("trying to attach xenpv before xenpci");
> + }
Can you use the identify method to add the xenpci device?
As I said earlier, I will reuse this code for ARM guest and this device
is not used on this architecture.
--
Julien Grall
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[PATCH v10 14/20] xen: introduce xenpv bus and a dummy pvcpu device
Since Xen PVH guests doesn't have ACPI, we need to create a dummy
bus so top level Xen devices can attach to it (instead of
attaching directly to the nexus) and a pvcpu device that will be used
to fill the pcpu->pc_device field.
---
sys/conf/files.amd64 |1 +
sys/conf/files.i386 |1 +
sys/x86/xen/xenpv.c | 128 ++
3 files changed, 130 insertions(+), 0 deletions(-)
create mode 100644 sys/x86/xen/xenpv.c
diff --git a/sys/conf/files.amd64 b/sys/conf/files.amd64
index a3491da..d7c98cc 100644
--- a/sys/conf/files.amd64
+++ b/sys/conf/files.amd64
@@ -570,3 +570,4 @@ x86/xen/hvm.c optionalxenhvm
x86/xen/xen_intr.c optionalxen | xenhvm
x86/xen/pv.c optionalxenhvm
x86/xen/pvcpu_enum.c optionalxenhvm
+x86/xen/xenpv.coptionalxenhvm
diff --git a/sys/conf/files.i386 b/sys/conf/files.i386
index 790296d..81142e3 100644
--- a/sys/conf/files.i386
+++ b/sys/conf/files.i386
@@ -603,3 +603,4 @@ x86/x86/tsc.c standard
x86/x86/delay.cstandard
x86/xen/hvm.c optional xenhvm
x86/xen/xen_intr.c optional xen | xenhvm
+x86/xen/xenpv.coptional xen | xenhvm
diff --git a/sys/x86/xen/xenpv.c b/sys/x86/xen/xenpv.c
new file mode 100644
index 000..e1282cf
--- /dev/null
+++ b/sys/x86/xen/xenpv.c
@@ -0,0 +1,128 @@
+/*
+ * Copyright (c) 2013 Roger Pau Monné
+ * 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
+__FBSDID("$FreeBSD$");
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static devclass_t xenpv_devclass;
+
+static void
+xenpv_identify(driver_t *driver, device_t parent)
+{
+ if (!xen_domain())
+ return;
+
+ /* Make sure there's only one xenpv device. */
+ if (devclass_get_device(xenpv_devclass, 0))
+ return;
+
+ /*
+* Use a high order number so xenpv is attached after
+* xenpci on HVM guests.
+*/
+ BUS_ADD_CHILD(parent, 200, "xenpv", 0);
+}
+
+static int
+xenpv_probe(device_t dev)
+{
+
+ device_set_desc(dev, "Xen PV bus");
+ device_quiet(dev);
+ return (BUS_PROBE_NOWILDCARD);
+}
+
+static int
+xenpv_attach(device_t dev)
+{
+ device_t child;
+
+ if (xen_hvm_domain()) {
+ device_t xenpci;
+ devclass_t dc;
+
+ /* Make sure xenpci has been attached */
+ dc = devclass_find("xenpci");
+ if (dc == NULL)
+ panic("unable to find xenpci devclass");
+
+ xenpci = devclass_get_device(dc, 0);
+ if (xenpci == NULL)
+ panic("unable to find xenpci device");
+
+ if (!device_is_attached(xenpci))
+ panic("trying to attach xenpv before xenpci");
+ }
+
+ /*
+* Let our child drivers identify any child devices that they
+* can find. Once that is done attach any devices that we
+* found.
+*/
+ bus_generic_probe(dev);
+ bus_generic_attach(dev);
+
+ if (!devclass_get_device(devclass_find("isa"), 0)) {
+ child = BUS_ADD_CHILD(dev, 0, "isa", 0);
+ if (child == NULL)
+ panic("xenpv_attach isa");
+ device_probe_and_attach(child);
+ }
+
+ return 0;
+}
+
+static device_method_t xenpv_methods[] = {
+ /* Device interface */
+ DEVMETHOD(device_identify, xenpv_identify),
+ DEVMETHOD(device_probe, xenpv_probe),
+
