[PATCH RFC 00/23] tools: add support for FreeBSD

[PATCH RFC 00/23] tools: add support for FreeBSD

[Roger Pau Monne]

The following series enables building (and using) the Xen toolstack on 
a FreeBSD PVH Dom0.

The FreeBSD sources used to test this series can be found at:

git://xenbits.xen.org/people/royger/freebsd.git branch pvh_dom0_v3
http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvh_dom0_v3

I've successfully tested PV and HVM domains, but right now only 
qemu-xen (aka qemu-upstream) is supported on FreeBSD (in order to 
avoid the build system from trying to compile qemu-trad pass the 
following option to configure: --disable-qemu-traditional). I'm not 
sure if there's any gain from also having qemu-trad, so I would 
suggest to automatically disable it on FreeBSD (like we do for ARM).

Some patches for Qemu and SeaBIOS are needed, which are still pending 
approval from their respective upstreams:

http://marc.info/?l=xen-devel&m=139763253311569
http://marc.info/?l=xen-devel&m=139755086616838&w=2

Thanks for the review, Roger.

[PATCH RFC 01/23] build: set FreeBSD specific build variables

[Roger Pau Monne]

This is very similar to what we do in order to build on NetBSD.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 config/FreeBSD.mk |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/config/FreeBSD.mk b/config/FreeBSD.mk
index b421a1c..1b4c74c 100644
--- a/config/FreeBSD.mk
+++ b/config/FreeBSD.mk
@@ -1 +1,8 @@
 include $(XEN_ROOT)/config/StdGNU.mk
+
+DLOPEN_LIBS =
+
+# No wget on FreeBSD base system
+WGET = ftp
+
+CONFIG_DIR = $(PREFIX)/etc
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 01/23] build: set FreeBSD specific build variables

[Ian Jackson]

Roger Pau Monne writes ("[PATCH RFC 01/23] build: set FreeBSD specific build variables"):
> This is very similar to what we do in order to build on NetBSD.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Re: [PATCH RFC 01/23] build: set FreeBSD specific build variables

[Ian Campbell]

On Wed, 2014-04-16 at 16:13 +0200, Roger Pau Monne wrote:
> This is very similar to what we do in order to build on NetBSD.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[PATCH RFC 02/23] configure: make the libaio test non-fatal on OSes different than Linux

[Roger Pau Monne]

libaio is only present on Linux systems, so make the configure test
that checks for libaio non-fatal is the host OS is different than
Linux.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
Please re-run autoconf after applying this patch.
---
 tools/configure.ac |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/tools/configure.ac b/tools/configure.ac
index a62faf8..eb54098 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -220,7 +220,13 @@ AC_CHECK_HEADER([lzo/lzo1x.h], [
 AC_CHECK_LIB([lzo2], [lzo1x_decompress], [zlib="$zlib -DHAVE_LZO1X -llzo2"])
 ])
 AC_SUBST(zlib)
-AC_CHECK_LIB([aio], [io_setup], [], [AC_MSG_ERROR([Could not find libaio])])
+AC_CHECK_LIB([aio], [io_setup], [], [
+    case "$host_os" in
+    linux*)
+        AC_MSG_ERROR([Could not find libaio])
+        ;;
+    esac
+])
 AC_SUBST(system_aio)
 AC_CHECK_LIB([crypto], [MD5], [], [AC_MSG_ERROR([Could not find libcrypto])])
 AX_CHECK_EXTFS
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[PATCH RFC 02/23] configure: make the libaio test non-fatal on OSes different than Linux

[Ian Jackson]

Roger Pau Monne writes ("[PATCH RFC 02/23] configure: make the libaio test non-fatal on OSes different than Linux"):
> libaio is only present on Linux systems, so make the configure test
> that checks for libaio non-fatal is the host OS is different than
> Linux.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

> Please re-run autoconf after applying this patch.

Can you move that just before, rather than just after, the S-o-b ?
That will make it less likely to be overlooked I think.

Thanks,
Ian.

Re: [PATCH RFC 02/23] configure: make the libaio test non-fatal on OSes different than Linux

[Roger Pau Monné]

On 17/04/14 18:21, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH RFC 02/23] configure: make the libaio test non-fatal on OSes different than Linux"):
>> libaio is only present on Linux systems, so make the configure test
>> that checks for libaio non-fatal is the host OS is different than
>> Linux.
>>
>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
>> Please re-run autoconf after applying this patch.
> 
> Can you move that just before, rather than just after, the S-o-b ?
> That will make it less likely to be overlooked I think.

Sure, I usually put those kind of notes after the S-o-b, so it's not
included in the actual commit message.

Roger.

Re: [PATCH RFC 02/23] configure: make the libaio test non-fatal on OSes different than Linux

[Ian Campbell]

On Wed, 2014-04-16 at 16:13 +0200, Roger Pau Monne wrote:
> libaio is only present on Linux systems, so make the configure test
> that checks for libaio non-fatal is the host OS is different than
> Linux.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> ---
> Please re-run autoconf after applying this patch.
> ---
>  tools/configure.ac |    8 +++++++-
>  1 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/configure.ac b/tools/configure.ac
> index a62faf8..eb54098 100644
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -220,7 +220,13 @@ AC_CHECK_HEADER([lzo/lzo1x.h], [
>  AC_CHECK_LIB([lzo2], [lzo1x_decompress], [zlib="$zlib -DHAVE_LZO1X -llzo2"])
>  ])
>  AC_SUBST(zlib)
> -AC_CHECK_LIB([aio], [io_setup], [], [AC_MSG_ERROR([Could not find libaio])])
> +AC_CHECK_LIB([aio], [io_setup], [], [
> +    case "$host_os" in
> +    linux*)
> +        AC_MSG_ERROR([Could not find libaio])
> +        ;;
> +    esac
> +])

AFAICT aio is used only by blktap (1 and 2), so you could make this
entire test conditional on either of those being enabled and by
extension it would then be dependent on Linux.

Ian.

>  AC_SUBST(system_aio)
>  AC_CHECK_LIB([crypto], [MD5], [], [AC_MSG_ERROR([Could not find libcrypto])])
>  AX_CHECK_EXTFS



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[PATCH RFC 03/23] include: import FreeBSD headers for evtchn and privcmd devices

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/include/xen-sys/FreeBSD/evtchn.h  |   87 +++++++++++++++++++++++++++++++
 tools/include/xen-sys/FreeBSD/privcmd.h |   64 ++++++++++++++++++++++
 2 files changed, 151 insertions(+), 0 deletions(-)
 create mode 100644 tools/include/xen-sys/FreeBSD/evtchn.h
 create mode 100644 tools/include/xen-sys/FreeBSD/privcmd.h

diff --git a/tools/include/xen-sys/FreeBSD/evtchn.h b/tools/include/xen-sys/FreeBSD/evtchn.h
new file mode 100644
index 0000000..00fa67e
--- /dev/null
+++ b/tools/include/xen-sys/FreeBSD/evtchn.h
@@ -0,0 +1,87 @@
+/******************************************************************************
+ * evtchn.h
+ * 
+ * Interface to /dev/xen/evtchn.
+ * 
+ * Copyright (c) 2003-2005, K A Fraser
+ * 
+ * This file may be distributed separately from the Linux kernel, or
+ * incorporated into other software packages, subject to the following license:
+ * 
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ * 
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ * 
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * $FreeBSD$
+ */
+
+#ifndef __XEN_EVTCHN_H__
+#define __XEN_EVTCHN_H__
+
+/*
+ * Bind a fresh port to VIRQ @virq.
+ */
+#define IOCTL_EVTCHN_BIND_VIRQ				\
+	_IOWR('E', 4, struct ioctl_evtchn_bind_virq)
+struct ioctl_evtchn_bind_virq {
+	unsigned int virq;
+	unsigned int port;
+};
+
+/*
+ * Bind a fresh port to remote <@remote_domain, @remote_port>.
+ */
+#define IOCTL_EVTCHN_BIND_INTERDOMAIN			\
+	_IOWR('E', 5, struct ioctl_evtchn_bind_interdomain)
+struct ioctl_evtchn_bind_interdomain {
+	unsigned int remote_domain, remote_port;
+	unsigned int port;
+};
+
+/*
+ * Allocate a fresh port for binding to @remote_domain.
+ */
+#define IOCTL_EVTCHN_BIND_UNBOUND_PORT			\
+	_IOWR('E', 6, struct ioctl_evtchn_bind_unbound_port)
+struct ioctl_evtchn_bind_unbound_port {
+	unsigned int remote_domain;
+	unsigned int port;
+};
+
+/*
+ * Unbind previously allocated @port.
+ */
+#define IOCTL_EVTCHN_UNBIND				\
+	_IOW('E', 7, struct ioctl_evtchn_unbind)
+struct ioctl_evtchn_unbind {
+	unsigned int port;
+};
+
+/*
+ * Send event to previously allocated @port.
+ */
+#define IOCTL_EVTCHN_NOTIFY				\
+	_IOW('E', 8, struct ioctl_evtchn_notify)
+struct ioctl_evtchn_notify {
+	unsigned int port;
+};
+
+/* Clear and reinitialise the event buffer. Clear error condition. */
+#define IOCTL_EVTCHN_RESET				\
+	_IO('E', 9)
+
+#endif /* __XEN_EVTCHN_H__ */
diff --git a/tools/include/xen-sys/FreeBSD/privcmd.h b/tools/include/xen-sys/FreeBSD/privcmd.h
new file mode 100644
index 0000000..a2a16ed
--- /dev/null
+++ b/tools/include/xen-sys/FreeBSD/privcmd.h
@@ -0,0 +1,64 @@
+/******************************************************************************
+ * privcmd.h
+ * 
+ * Interface to /proc/xen/privcmd.
+ * 
+ * Copyright (c) 2003-2005, K A Fraser
+ * 
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ * 
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ * 
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ * 
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef __XEN_PRIVCMD_H__
+#define __XEN_PRIVCMD_H__
+
+struct ioctl_privcmd_hypercall
+{
+	unsigned long op; /* hypercall number */
+	unsigned long arg[5]; /* arguments */
+	long retval; /* return value */
+};
+typedef struct ioctl_privcmd_hypercall privcmd_hypercall_t;
+
+struct ioctl_privcmd_mmapbatch {
+	int num;     /* number of pages to populate */
+	domid_t dom; /* target domain */
+	unsigned long addr;  /* virtual address */
+	const xen_pfn_t *arr; /* array of mfns */
+	int *err; /* array of error codes */
+};
+typedef struct ioctl_privcmd_mmapbatch privcmd_mmapbatch_t;
+
+typedef struct privcmd_mmap_entry {
+	unsigned long va;
+	unsigned long mfn;
+	unsigned long npages;
+} privcmd_mmap_entry_t;
+
+#define IOCTL_PRIVCMD_HYPERCALL					\
+	_IOWR('E', 0, struct ioctl_privcmd_hypercall)
+#define IOCTL_PRIVCMD_MMAPBATCH					\
+	_IOWR('E', 1, struct ioctl_privcmd_mmapbatch)
+
+#endif /* !__XEN_PRIVCMD_H__ */
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 03/23] include: import FreeBSD headers for evtchn and privcmd devices

[Ian Jackson]

Roger Pau Monne writes ("[PATCH RFC 03/23] include: import FreeBSD headers for evtchn and privcmd devices"):
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>

Is it usual, then in the FreeBSD world, for an application program to
take a copy of kernel headers defining ioctls etc. ?  This seems
surprising to me.  It would seem more sensible for the application to
use the headers installed on the build host.

Ian.

Re: [PATCH RFC 03/23] include: import FreeBSD headers for evtchn and privcmd devices

[Roger Pau Monné]

On 17/04/14 18:16, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH RFC 03/23] include: import FreeBSD headers for evtchn and privcmd devices"):
>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
>> Cc: Ian Campbell <ian.campbell@citrix.com>
> 
> Is it usual, then in the FreeBSD world, for an application program to
> take a copy of kernel headers defining ioctls etc. ?  This seems
> surprising to me.  It would seem more sensible for the application to
> use the headers installed on the build host.

I would say it's certainly not common, but every OS with Dom0 support
seems to do it (take a look at tools/include/xen-sys).

Not sure if this was done in the past to allow compiling the toolstack
on a host without a xen-classic kernel (which I guess was the only one
to have the proper headers for user-space devices).

Roger.

Re: [PATCH RFC 03/23] include: import FreeBSD headers for evtchn and privcmd devices

[Ian Campbell]

On Tue, 2014-04-22 at 16:35 +0200, Roger Pau Monné wrote:
> On 17/04/14 18:16, Ian Jackson wrote:
> > Roger Pau Monne writes ("[PATCH RFC 03/23] include: import FreeBSD headers for evtchn and privcmd devices"):
> >> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> >> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
> >> Cc: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Is it usual, then in the FreeBSD world, for an application program to
> > take a copy of kernel headers defining ioctls etc. ?  This seems
> > surprising to me.  It would seem more sensible for the application to
> > use the headers installed on the build host.

Normally such headers come from the libc rather than the kernel
directly. We could upstream our ioctl definitions into glibc I suppose.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 03/23] include: import FreeBSD headers for evtchn and privcmd devices

[Ian Campbell]

On Wed, 2014-04-16 at 16:13 +0200, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[PATCH RFC 04/23] libxc: add support for FreeBSD

[Roger Pau Monne]

Add the FreeBSD implementation of the privcmd and evtchn devices
interface.

The evtchn device interface is the same as the Linux one, while the
privcmd map interface is simplified because FreeBSD only supports
IOCTL_PRIVCMD_MMAPBATCH.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxc/Makefile           |    1 +
 tools/libxc/xc_freebsd.c       |   72 +++++++
 tools/libxc/xc_freebsd_osdep.c |  405 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 478 insertions(+), 0 deletions(-)
 create mode 100644 tools/libxc/xc_freebsd.c
 create mode 100644 tools/libxc/xc_freebsd_osdep.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 2cca2b2..7f9b672 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -36,6 +36,7 @@ CTRL_SRCS-y       += xtl_core.c
 CTRL_SRCS-y       += xtl_logger_stdio.c
 CTRL_SRCS-$(CONFIG_X86) += xc_pagetab.c
 CTRL_SRCS-$(CONFIG_Linux) += xc_linux.c xc_linux_osdep.c
+CTRL_SRCS-$(CONFIG_FreeBSD) += xc_freebsd.c xc_freebsd_osdep.c
 CTRL_SRCS-$(CONFIG_SunOS) += xc_solaris.c
 CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c
 CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
diff --git a/tools/libxc/xc_freebsd.c b/tools/libxc/xc_freebsd.c
new file mode 100644
index 0000000..8d169f4
--- /dev/null
+++ b/tools/libxc/xc_freebsd.c
@@ -0,0 +1,72 @@
+/******************************************************************************
+ *
+ * Copyright 2006 Sun Microsystems, Inc.  All rights reserved.
+ * Use is subject to license terms.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include "xc_private.h"
+
+/* Optionally flush file to disk and discard page cache */
+void discard_file_cache(xc_interface *xch, int fd, int flush) 
+{
+    off_t cur = 0;
+    int saved_errno = errno;
+
+    if ( flush && (fsync(fd) < 0) )
+        goto out;
+
+    /* 
+     * Calculate last page boundary of amount written so far 
+     * unless we are flushing in which case entire cache
+     * is discarded.
+     */
+    if ( !flush )
+    {
+        if ( (cur = lseek(fd, 0, SEEK_CUR)) == (off_t)-1 )
+            cur = 0;
+        cur &= ~(XC_PAGE_SIZE-1);
+    }
+
+    /* Discard from the buffer cache. */
+    if ( posix_fadvise(fd, 0, cur, POSIX_FADV_DONTNEED) < 0 )
+        goto out;
+
+ out:
+    errno = saved_errno;
+}
+
+void *xc_memalign(xc_interface *xch, size_t alignment, size_t size)
+{
+    int ret;
+    void *ptr;
+
+    ret = posix_memalign(&ptr, alignment, size);
+    if ( ret != 0 || !ptr )
+        return NULL;
+
+    return ptr;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_freebsd_osdep.c b/tools/libxc/xc_freebsd_osdep.c
new file mode 100644
index 0000000..151d3bf
--- /dev/null
+++ b/tools/libxc/xc_freebsd_osdep.c
@@ -0,0 +1,405 @@
+ /******************************************************************************
+ *
+ * Copyright 2006 Sun Microsystems, Inc.  All rights reserved.
+ * Use is subject to license terms.
+ *
+ * xc_gnttab functions:
+ * Copyright (c) 2007-2008, D G Murray <Derek.Murray@cl.cam.ac.uk>
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <errno.h>
+#include <fcntl.h>
+#include <stdint.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+
+#include <sys/mman.h>
+#include <sys/ioctl.h>
+
+#include <xen/memory.h>
+#include <xen/sys/evtchn.h>
+
+#include "xenctrl.h"
+#include "xenctrlosdep.h"
+
+#define PRIVCMD_DEV     "/dev/xen/privcmd"
+#define EVTCHN_DEV      "/dev/xen/evtchn"
+
+#define PERROR(_m, _a...) xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
+                  " (%d = %s)", ## _a , errno, xc_strerror(xch, errno))
+
+/*------------------------- Privcmd device interface -------------------------*/
+static xc_osdep_handle freebsd_privcmd_open(xc_interface *xch)
+{
+    int flags, saved_errno;
+    int fd = open(PRIVCMD_DEV, O_RDWR);
+
+    if ( fd == -1 )
+    {
+        PERROR("Could not obtain handle on privileged command interface "
+               PRIVCMD_DEV);
+        return XC_OSDEP_OPEN_ERROR;
+    }
+
+    /*
+     * Although we return the file handle as the 'xc handle' the API
+     * does not specify / guarentee that this integer is in fact
+     * a file handle. Thus we must take responsiblity to ensure
+     * it doesn't propagate (ie leak) outside the process.
+     */
+    if ( (flags = fcntl(fd, F_GETFD)) < 0 )
+    {
+        PERROR("Could not get file handle flags");
+        goto error;
+    }
+
+    flags |= FD_CLOEXEC;
+
+    if ( fcntl(fd, F_SETFD, flags) < 0 )
+    {
+        PERROR("Could not set file handle flags");
+        goto error;
+    }
+
+    return (xc_osdep_handle)fd;
+
+ error:
+    saved_errno = errno;
+    close(fd);
+    errno = saved_errno;
+
+    return XC_OSDEP_OPEN_ERROR;
+}
+
+static int freebsd_privcmd_close(xc_interface *xch, xc_osdep_handle h)
+{
+    int fd = (int)h;
+
+    return close(fd);
+}
+
+/*------------------------ Privcmd hypercall interface -----------------------*/
+static void *freebsd_privcmd_alloc_hypercall_buffer(xc_interface *xch,
+                                                    xc_osdep_handle h,
+                                                    int npages)
+{
+    size_t size = npages * XC_PAGE_SIZE;
+    void *p;
+
+    /* Address returned by mmap is page aligned. */
+    p = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
+             -1, 0);
+    if (p == NULL)
+        return NULL;
+
+    /*
+     * Since FreeBSD doesn't have the MAP_LOCKED flag,
+     * lock memory using mlock.
+     */
+    if ( mlock(p, size) < 0 )
+    {
+        munmap(p, size);
+        return NULL;
+    }
+
+    return p;
+}
+
+static void freebsd_privcmd_free_hypercall_buffer(xc_interface *xch,
+                                                  xc_osdep_handle h, void *ptr,
+                                                  int npages)
+{
+
+    /* Unlock pages */
+    munlock(ptr, npages * XC_PAGE_SIZE);
+
+    munmap(ptr, npages * XC_PAGE_SIZE);
+}
+
+static int freebsd_privcmd_hypercall(xc_interface *xch, xc_osdep_handle h,
+                                     privcmd_hypercall_t *hypercall)
+{
+    int fd = (int)h;
+    int ret;
+
+    ret = ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, hypercall);
+
+    return (ret == 0) ? hypercall->retval : ret;
+}
+
+/*----------------------- Privcmd foreign map interface ----------------------*/
+static void *freebsd_privcmd_map_foreign_bulk(xc_interface *xch,
+                                               xc_osdep_handle h,
+                                               uint32_t dom, int prot,
+                                               const xen_pfn_t *arr, int *err,
+                                               unsigned int num)
+{
+    int fd = (int)h;
+    privcmd_mmapbatch_t ioctlx;
+    void *addr;
+    int rc;
+
+    addr = mmap(NULL, num << XC_PAGE_SHIFT, prot, MAP_SHARED, fd, 0);
+    if ( addr == MAP_FAILED )
+    {
+        PERROR("xc_map_foreign_batch: mmap failed");
+        return NULL;
+    }
+
+    ioctlx.num = num;
+    ioctlx.dom = dom;
+    ioctlx.addr = (unsigned long)addr;
+    ioctlx.arr = arr;
+    ioctlx.err = err;
+
+    rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH, &ioctlx);
+    if ( rc < 0 )
+    {
+        int saved_errno = errno;
+        PERROR("xc_map_foreign_batch: ioctl failed");
+        (void)munmap(addr, num << XC_PAGE_SHIFT);
+        errno = saved_errno;
+        return NULL;
+    }
+
+    return addr;
+}
+
+static void *freebsd_privcmd_map_foreign_range(xc_interface *xch,
+                                               xc_osdep_handle h,
+                                               uint32_t dom, int size, int prot,
+                                               unsigned long mfn)
+{
+    xen_pfn_t *arr;
+    int num;
+    int i;
+    void *ret;
+
+    num = (size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT;
+    arr = calloc(num, sizeof(xen_pfn_t));
+    if ( arr == NULL )
+        return NULL;
+
+    for ( i = 0; i < num; i++ )
+        arr[i] = mfn + i;
+
+    ret = xc_map_foreign_pages(xch, dom, prot, arr, num);
+    free(arr);
+    return ret;
+}
+
+static void *freebsd_privcmd_map_foreign_ranges(xc_interface *xch,
+                                                xc_osdep_handle h,
+                                                uint32_t dom, size_t size,
+                                                int prot, size_t chunksize,
+                                                privcmd_mmap_entry_t entries[],
+                                                int nentries)
+{
+    xen_pfn_t *arr;
+    int num_per_entry;
+    int num;
+    int i;
+    int j;
+    void *ret;
+
+    num_per_entry = chunksize >> XC_PAGE_SHIFT;
+    num = num_per_entry * nentries;
+    arr = calloc(num, sizeof(xen_pfn_t));
+    if ( arr == NULL )
+        return NULL;
+
+    for ( i = 0; i < nentries; i++ )
+        for ( j = 0; j < num_per_entry; j++ )
+            arr[i * num_per_entry + j] = entries[i].mfn + j;
+
+    ret = xc_map_foreign_pages(xch, dom, prot, arr, num);
+    free(arr);
+    return ret;
+}
+
+/*----------------------------- Privcmd handlers -----------------------------*/
+static struct xc_osdep_ops freebsd_privcmd_ops = {
+    .open = &freebsd_privcmd_open,
+    .close = &freebsd_privcmd_close,
+
+    .u.privcmd = {
+        .alloc_hypercall_buffer = &freebsd_privcmd_alloc_hypercall_buffer,
+        .free_hypercall_buffer = &freebsd_privcmd_free_hypercall_buffer,
+
+        .hypercall = &freebsd_privcmd_hypercall,
+
+        .map_foreign_bulk = &freebsd_privcmd_map_foreign_bulk,
+        .map_foreign_range = &freebsd_privcmd_map_foreign_range,
+        .map_foreign_ranges = &freebsd_privcmd_map_foreign_ranges,
+    },
+};
+
+/*-------------------------- Evtchn device interface -------------------------*/
+static xc_osdep_handle
+freebsd_evtchn_open(xc_evtchn *xce)
+{
+    int fd = open(EVTCHN_DEV, O_RDWR);
+    if ( fd == -1 )
+        return XC_OSDEP_OPEN_ERROR;
+
+    return (xc_osdep_handle)fd;
+}
+
+static int
+freebsd_evtchn_close(xc_evtchn *xce, xc_osdep_handle h)
+{
+    int fd = (int)h;
+    return close(fd);
+}
+
+static int
+freebsd_evtchn_fd(xc_evtchn *xce, xc_osdep_handle h)
+{
+    return (int)h;
+}
+
+/*------------------------------ Evtchn interface ----------------------------*/
+static int
+freebsd_evtchn_notify(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t port)
+{
+    int fd = (int)h;
+    struct ioctl_evtchn_notify notify;
+
+    notify.port = port;
+
+    return ioctl(fd, IOCTL_EVTCHN_NOTIFY, &notify);
+}
+
+static evtchn_port_or_error_t
+freebsd_evtchn_bind_unbound_port(xc_evtchn *xce, xc_osdep_handle h, int domid)
+{
+    int ret, fd = (int)h;
+    struct ioctl_evtchn_bind_unbound_port bind;
+
+    bind.remote_domain = domid;
+
+    ret = ioctl(fd, IOCTL_EVTCHN_BIND_UNBOUND_PORT, &bind);
+    return ( ret == 0 ) ? bind.port : ret;
+}
+
+static evtchn_port_or_error_t
+freebsd_evtchn_bind_interdomain(xc_evtchn *xce, xc_osdep_handle h, int domid,
+                                evtchn_port_t remote_port)
+{
+    int ret, fd = (int)h;
+    struct ioctl_evtchn_bind_interdomain bind;
+
+    bind.remote_domain = domid;
+    bind.remote_port = remote_port;
+
+    ret = ioctl(fd, IOCTL_EVTCHN_BIND_INTERDOMAIN, &bind);
+    return ( ret == 0 ) ? bind.port : ret;
+}
+
+static evtchn_port_or_error_t
+freebsd_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_handle h, unsigned int virq)
+{
+    int ret, fd = (int)h;
+    struct ioctl_evtchn_bind_virq bind;
+
+    bind.virq = virq;
+
+    ret = ioctl(fd, IOCTL_EVTCHN_BIND_VIRQ, &bind);
+    return ( ret == 0 ) ? bind.port : ret;
+}
+
+static int
+freebsd_evtchn_unbind(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t port)
+{
+    int fd = (int)h;
+    struct ioctl_evtchn_unbind unbind;
+
+    unbind.port = port;
+
+    return ioctl(fd, IOCTL_EVTCHN_UNBIND, &unbind);
+}
+
+static evtchn_port_or_error_t
+freebsd_evtchn_pending(xc_evtchn *xce, xc_osdep_handle h)
+{
+    int fd = (int)h;
+    evtchn_port_t port;
+
+    if ( read(fd, &port, sizeof(port)) != sizeof(port) )
+        return -1;
+
+    return port;
+}
+
+static int
+freebsd_evtchn_unmask(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t port)
+{
+    int fd = (int)h;
+
+    if ( write(fd, &port, sizeof(port)) != sizeof(port) )
+        return -1;
+    return 0;
+}
+
+/*----------------------------- Evtchn handlers ------------------------------*/
+static struct xc_osdep_ops freebsd_evtchn_ops = {
+    .open = &freebsd_evtchn_open,
+    .close = &freebsd_evtchn_close,
+
+    .u.evtchn = {
+        .fd = &freebsd_evtchn_fd,
+        .notify = &freebsd_evtchn_notify,
+        .bind_unbound_port = &freebsd_evtchn_bind_unbound_port,
+        .bind_interdomain = &freebsd_evtchn_bind_interdomain,
+        .bind_virq = &freebsd_evtchn_bind_virq,
+        .unbind = &freebsd_evtchn_unbind,
+        .pending = &freebsd_evtchn_pending,
+        .unmask = &freebsd_evtchn_unmask,
+    },
+};
+
+/*---------------------------- FreeBSD interface -----------------------------*/
+static struct xc_osdep_ops *
+freebsd_osdep_init(xc_interface *xch, enum xc_osdep_type type)
+{
+    switch ( type )
+    {
+    case XC_OSDEP_PRIVCMD:
+        return &freebsd_privcmd_ops;
+    case XC_OSDEP_EVTCHN:
+        return &freebsd_evtchn_ops;
+    default:
+        return NULL;
+    }
+}
+
+xc_osdep_info_t xc_osdep_info = {
+    .name = "FreeBSD Native OS interface",
+    .init = &freebsd_osdep_init,
+    .fake = 0,
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 04/23] libxc: add support for FreeBSD

[Ian Jackson]

Roger Pau Monne writes ("[PATCH RFC 04/23] libxc: add support for FreeBSD"):
> Add the FreeBSD implementation of the privcmd and evtchn devices
> interface.
> 
> The evtchn device interface is the same as the Linux one, while the
> privcmd map interface is simplified because FreeBSD only supports
> IOCTL_PRIVCMD_MMAPBATCH.
...
> +/* Optionally flush file to disk and discard page cache */
> +void discard_file_cache(xc_interface *xch, int fd, int flush) 
> +{

My main criticism of this is that much of this file is a (nearly)
verbatim copy of the Linux functions.  I think we should have a
conversation about other approaches that would allow us to share more
of the code.

Two options I can think of (which could perhaps be combined):
   xc_posix.c containing some "standard" versions
   #ifdeffery


Now, prompted by your patch to look at this function:

> +    off_t cur = 0;
> +    int saved_errno = errno;
> +
> +    if ( flush && (fsync(fd) < 0) )
> +        goto out;

This function has truly demented error behaviour, but this is not
your fault - you're just copying what the Linux one does.

I'm pretty sure that many of the callers expect this function to do
its thing and that if it doesn't work we might get corruption in the
guest.

> +    /* Discard from the buffer cache. */
> +    if ( posix_fadvise(fd, 0, cur, POSIX_FADV_DONTNEED) < 0 )
> +        goto out;

Which also means that the use of posix_fadvise is hardly safe.
fadvise can quite legally be a noop.


> +static xc_osdep_handle freebsd_privcmd_open(xc_interface *xch)
> +{
> +    int flags, saved_errno;
> +    int fd = open(PRIVCMD_DEV, O_RDWR);
> +
> +    if ( fd == -1 )
> +    {
> +        PERROR("Could not obtain handle on privileged command interface "
> +               PRIVCMD_DEV);
> +        return XC_OSDEP_OPEN_ERROR;

I think it would be better to use the "goto out" error handling
style.  Of course this function is a clone so really I'm complaining
about an existing function.

Maybe I should stop looking under this rock before I discover any more
rotting yak hair.

Ian.

Re: [PATCH RFC 04/23] libxc: add support for FreeBSD

[Ian Campbell]

On Thu, 2014-04-17 at 17:30 +0100, Ian Jackson wrote:
> > +    /* Discard from the buffer cache. */
> > +    if ( posix_fadvise(fd, 0, cur, POSIX_FADV_DONTNEED) < 0 )
> > +        goto out;
> 
> Which also means that the use of posix_fadvise is hardly safe.
> fadvise can quite legally be a noop.

I think that's ok, it's for "reducing the impact on dom0" not
correctness, according to the commit which added it:

commit e0b421d24279d3cce426c0df4bf6d8734c6ce325
Author: Keir Fraser <keir@xensource.com>
Date:   Sat Feb 24 14:48:17 2007 +0000

    Reduce impact of saving/restoring/dumping large domains on Dom0 memory
    usage by means of fadvise64() to tell the OS to discard the cache
    pages used for the save/dump file.
    
    Signed-off-by: Simon Graham <Simon.Graham@stratus.com>

(I presume fadvise implemented as a nop should still return success)

Ian.

Re: [PATCH RFC 04/23] libxc: add support for FreeBSD

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH RFC 04/23] libxc: add support for FreeBSD"):
> On Thu, 2014-04-17 at 17:30 +0100, Ian Jackson wrote:
> > > +    /* Discard from the buffer cache. */
> > > +    if ( posix_fadvise(fd, 0, cur, POSIX_FADV_DONTNEED) < 0 )
> > > +        goto out;
> > 
> > Which also means that the use of posix_fadvise is hardly safe.
> > fadvise can quite legally be a noop.
> 
> I think that's ok, it's for "reducing the impact on dom0" not
> correctness, according to the commit which added it:

Oh, good.  Thanks for digging that up.

Ian.

[PATCH RFC 05/23] libxc: remove usage of "daylight" variable

[Roger Pau Monne]

FreeBSD doesn't implement the XSI extension that mandates the presence
of the daylight variable as described in:

http://pubs.opengroup.org/onlinepubs/009696799/functions/tzset.html

So avoid using it for portability reasons. Use tm_isdst instead to
decide if daylight savings time conversions should be used or not.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxc/xtl_logger_stdio.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxc/xtl_logger_stdio.c b/tools/libxc/xtl_logger_stdio.c
index 47ee257..d8646e0 100644
--- a/tools/libxc/xtl_logger_stdio.c
+++ b/tools/libxc/xtl_logger_stdio.c
@@ -64,7 +64,7 @@ static void stdiostream_vmessage(xentoollog_logger *logger_in,
         fprintf(lg->f, "%04d-%02d-%02d %02d:%02d:%02d %s ",
                 lt->tm_year+1900, lt->tm_mon+1, lt->tm_mday,
                 lt->tm_hour, lt->tm_min, lt->tm_sec,
-                tzname[daylight ? !!lt->tm_isdst : 0]);
+                tzname[!!lt->tm_isdst]);
     }
     if (lg->flags & XTL_STDIOSTREAM_SHOW_PID)
         fprintf(lg->f, "[%lu] ", (unsigned long)getpid());
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 05/23] libxc: remove usage of "daylight" variable

[Ian Jackson]

Roger Pau Monne writes ("[PATCH RFC 05/23] libxc: remove usage of "daylight" variable"):
> FreeBSD doesn't implement the XSI extension that mandates the presence
> of the daylight variable as described in:
> 
> http://pubs.opengroup.org/onlinepubs/009696799/functions/tzset.html
> 
> So avoid using it for portability reasons. Use tm_isdst instead to
> decide if daylight savings time conversions should be used or not.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

Re: [PATCH RFC 05/23] libxc: remove usage of "daylight" variable

[Ian Campbell]

On Wed, 2014-04-16 at 16:13 +0200, Roger Pau Monne wrote:
> FreeBSD doesn't implement the XSI extension that mandates the presence
> of the daylight variable as described in:
> 
> http://pubs.opengroup.org/onlinepubs/009696799/functions/tzset.html

Wow, what an interesting thing to expose.


> So avoid using it for portability reasons. Use tm_isdst instead to
> decide if daylight savings time conversions should be used or not.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxc/xtl_logger_stdio.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxc/xtl_logger_stdio.c b/tools/libxc/xtl_logger_stdio.c
> index 47ee257..d8646e0 100644
> --- a/tools/libxc/xtl_logger_stdio.c
> +++ b/tools/libxc/xtl_logger_stdio.c
> @@ -64,7 +64,7 @@ static void stdiostream_vmessage(xentoollog_logger *logger_in,
>          fprintf(lg->f, "%04d-%02d-%02d %02d:%02d:%02d %s ",
>                  lt->tm_year+1900, lt->tm_mon+1, lt->tm_mday,
>                  lt->tm_hour, lt->tm_min, lt->tm_sec,
> -                tzname[daylight ? !!lt->tm_isdst : 0]);
> +                tzname[!!lt->tm_isdst]);
>      }
>      if (lg->flags & XTL_STDIOSTREAM_SHOW_PID)
>          fprintf(lg->f, "[%lu] ", (unsigned long)getpid());



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[PATCH RFC 06/23] libxc: remove include of malloc.h

[Roger Pau Monne]

The malloc set of functions should have their prototypes in stdlib.h
according to:

http://pubs.opengroup.org/onlinepubs/009695399/functions/malloc.html

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxc/xg_private.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/tools/libxc/xg_private.c b/tools/libxc/xg_private.c
index a914068..c52cb44 100644
--- a/tools/libxc/xg_private.c
+++ b/tools/libxc/xg_private.c
@@ -21,7 +21,6 @@
 #include <stdlib.h>
 #include <unistd.h>
 #include <zlib.h>
-#include <malloc.h>
 
 #include "xg_private.h"
 
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 06/23] libxc: remove include of malloc.h

[Ian Jackson]

Roger Pau Monne writes ("[PATCH RFC 06/23] libxc: remove include of malloc.h"):
> The malloc set of functions should have their prototypes in stdlib.h
> according to:
> 
> http://pubs.opengroup.org/onlinepubs/009695399/functions/malloc.html
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

[PATCH RFC 07/23] libelf: add defines for bswap_* functions for FreeBSD

[Roger Pau Monne]

This maps bswap_* functions used in libelf to their FreeBSD
counterparts.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 xen/common/libelf/libelf-private.h |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/xen/common/libelf/libelf-private.h b/xen/common/libelf/libelf-private.h
index f4b79c7..854a0d7 100644
--- a/xen/common/libelf/libelf-private.h
+++ b/xen/common/libelf/libelf-private.h
@@ -61,6 +61,11 @@
 #define bswap_16(x) swap16(x)
 #define bswap_32(x) swap32(x)
 #define bswap_64(x) swap64(x)
+#elif defined(__FreeBSD__)
+#include <sys/endian.h>
+#define bswap_16(x) bswap16(x)
+#define bswap_32(x) bswap32(x)
+#define bswap_64(x) bswap64(x)
 #elif defined(__linux__) || defined(__Linux__) || defined(__MINIOS__)
 #include <byteswap.h>
 #else
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 07/23] libelf: add defines for bswap_* functions for FreeBSD

[Ian Jackson]

Roger Pau Monne writes ("[PATCH RFC 07/23] libelf: add defines for bswap_* functions for FreeBSD"):
> This maps bswap_* functions used in libelf to their FreeBSD
> counterparts.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Looks plausible, although I haven't chased up any docs.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

Re: [PATCH RFC 07/23] libelf: add defines for bswap_* functions for FreeBSD

[Ian Campbell]

On Wed, 2014-04-16 at 16:13 +0200, Roger Pau Monne wrote:
> This maps bswap_* functions used in libelf to their FreeBSD
> counterparts.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Bit you could consider combining with the identical NetBSD case
#elif defined(ONE thing) || defined(ANOTHER)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[PATCH RFC 08/23] configure: add checks for endian.h and sys/endian.h

[Roger Pau Monne]

In order to know which one to include when building
xc_dom_decompress_lz4.c

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
Please run autoconf after applying this patch.
---
 tools/config.h.in                   |    6 ++++++
 tools/configure.ac                  |    2 +-
 tools/libxc/Makefile                |    1 +
 tools/libxc/xc_dom_decompress_lz4.c |    4 ++++
 4 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/tools/config.h.in b/tools/config.h.in
index 015f2a1..283cee7 100644
--- a/tools/config.h.in
+++ b/tools/config.h.in
@@ -51,6 +51,12 @@
 /* Define to 1 if you have the <yajl/yajl_version.h> header file. */
 #undef HAVE_YAJL_YAJL_VERSION_H
 
+/* Define to 1 if you have the <endian.h> header file. */
+#undef HAVE_ENDIAN_H
+
+/* Define to 1 if you have the <sys/endian.h> header file. */
+#undef HAVE_SYS_ENDIAN_H
+
 /* Define curses header to use */
 #undef INCLUDE_CURSES_H
 
diff --git a/tools/configure.ac b/tools/configure.ac
index eb54098..3b8db0a 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -247,7 +247,7 @@ AC_CHECK_LIB([fdt], [fdt_create], [], [AC_MSG_ERROR([Could not find libfdt])])
 esac
 
 # Checks for header files.
-AC_CHECK_HEADERS([yajl/yajl_version.h sys/eventfd.h])
+AC_CHECK_HEADERS([yajl/yajl_version.h sys/eventfd.h endian.h sys/endian.h])
 
 AC_OUTPUT()
 
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 7f9b672..3e3678f 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -90,6 +90,7 @@ OSDEP_SRCS-y                 += xenctrl_osdep_ENOSYS.c
 
 CFLAGS   += -Werror -Wmissing-prototypes
 CFLAGS   += -I. $(CFLAGS_xeninclude)
+CFLAGS   += -include $(XEN_ROOT)/tools/config.h
 
 # Needed for posix_fadvise64() in xc_linux.c
 CFLAGS-$(CONFIG_Linux) += -D_GNU_SOURCE
diff --git a/tools/libxc/xc_dom_decompress_lz4.c b/tools/libxc/xc_dom_decompress_lz4.c
index 08272fe..7f97364 100644
--- a/tools/libxc/xc_dom_decompress_lz4.c
+++ b/tools/libxc/xc_dom_decompress_lz4.c
@@ -1,7 +1,11 @@
 #include <stdio.h>
 #include <stdlib.h>
 #include <inttypes.h>
+#if defined(HAVE_ENDIAN_H)
 #include <endian.h>
+#elif defined(HAVE_SYS_ENDIAN_H)
+#include <sys/endian.h>
+#endif
 #include <stdint.h>
 
 #include "xg_private.h"
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[PATCH RFC 08/23] configure: add checks for endian.h and sys/endian.h

[Ian Jackson]

Roger Pau Monne writes ("[PATCH RFC 08/23] configure: add checks for endian.h and sys/endian.h"):
> In order to know which one to include when building
> xc_dom_decompress_lz4.c

Does BSD's sys/endian.h define the same things as endian.h ?

Ian.

[PATCH RFC 09/23] lz4: add support for OSes that don't have asm/unaligned.h

[Roger Pau Monne]

Add a configure check for asm/unaligned.h presence, and if it's not
available open-code the necessary functions for lz4.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/config.h.in     |    3 +++
 tools/configure.ac    |    2 +-
 xen/common/lz4/defs.h |   42 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 46 insertions(+), 1 deletions(-)

diff --git a/tools/config.h.in b/tools/config.h.in
index 283cee7..709a51d 100644
--- a/tools/config.h.in
+++ b/tools/config.h.in
@@ -57,6 +57,9 @@
 /* Define to 1 if you have the <sys/endian.h> header file. */
 #undef HAVE_SYS_ENDIAN_H
 
+/* Define to 1 if you have the <asm/unaligned.h> header file. */
+#undef HAVE_ASM_UNALIGNED_H
+
 /* Define curses header to use */
 #undef INCLUDE_CURSES_H
 
diff --git a/tools/configure.ac b/tools/configure.ac
index 3b8db0a..cf30254 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -247,7 +247,7 @@ AC_CHECK_LIB([fdt], [fdt_create], [], [AC_MSG_ERROR([Could not find libfdt])])
 esac
 
 # Checks for header files.
-AC_CHECK_HEADERS([yajl/yajl_version.h sys/eventfd.h endian.h sys/endian.h])
+AC_CHECK_HEADERS([yajl/yajl_version.h sys/eventfd.h endian.h sys/endian.h asm/unaligned.h])
 
 AC_OUTPUT()
 
diff --git a/xen/common/lz4/defs.h b/xen/common/lz4/defs.h
index f46df08..f4b810a 100644
--- a/xen/common/lz4/defs.h
+++ b/xen/common/lz4/defs.h
@@ -23,7 +23,49 @@ static inline u32 INIT get_unaligned_le32(const void *p)
 	return le32_to_cpup(p);
 }
 #else
+#ifdef HAVE_ASM_UNALIGNED_H
 #include <asm/unaligned.h>
+#else
+
+#if defined(HAVE_ENDIAN_H)
+#include <endian.h>
+#elif defined(HAVE_SYS_ENDIAN_H)
+#include <sys/endian.h>
+#endif
+
+#define le16_to_cpu(x)	le16toh(x)
+#define le32_to_cpu(x)	le32toh(x)
+
+extern void bad_unaligned_access_length(void) __attribute__((noreturn));
+
+struct __una_u32 { uint32_t x __attribute__((packed)); };
+struct __una_u16 { uint16_t x __attribute__((packed)); };
+
+static inline uint16_t __uldw(const uint16_t *addr)
+{
+	const struct __una_u16 *ptr = (const struct __una_u16 *) addr;
+	return ptr->x;
+}
+static inline uint32_t __uldl(const uint32_t *addr)
+{
+	const struct __una_u32 *ptr = (const struct __una_u32 *) addr;
+	return ptr->x;
+}
+#define __get_unaligned(ptr, size) ({		\
+	uint64_t __val;				\
+	switch (size) {				\
+	case 2:					\
+		__val = __uldw(ptr);		\
+		break;				\
+	case 4:					\
+		__val = __uldl(ptr);		\
+		break;				\
+	default:				\
+		bad_unaligned_access_length();	\
+	};					\
+	__val;					\
+})
+#endif /* !HAVE_ASM_UNALIGNED_H */
 
 static inline u16 INIT get_unaligned_le16(const void *p)
 {
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 09/23] lz4: add support for OSes that don't have asm/unaligned.h

[Ian Jackson]

Roger Pau Monne writes ("[PATCH RFC 09/23] lz4: add support for OSes that don't have asm/unaligned.h"):
> Add a configure check for asm/unaligned.h presence, and if it's not
> available open-code the necessary functions for lz4.

Where did this code come from ?

Is there nothing in the FreeBSD environment that we could reuse ?

> +struct __una_u32 { uint32_t x __attribute__((packed)); };
> +struct __una_u16 { uint16_t x __attribute__((packed)); };

Are you sure this actually works ?  I can't see anything in the GCC
4.4 docs which requires the compiler to generate special code to
access such a variable.

Ian.

Re: [PATCH RFC 09/23] lz4: add support for OSes that don't have asm/unaligned.h

[Roger Pau Monné]

On 17/04/14 19:00, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH RFC 09/23] lz4: add support for OSes that don't have asm/unaligned.h"):
>> Add a configure check for asm/unaligned.h presence, and if it's not
>> available open-code the necessary functions for lz4.
> 
> Where did this code come from ?

This came from the Linux kernel, see:

http://lxr.free-electrons.com/source/include/asm-generic/unaligned.h?v=2.6.25#L80

> 
> Is there nothing in the FreeBSD environment that we could reuse ?

I think there's nothing in FreeBSD that we could use to replace this
functions.

> 
>> +struct __una_u32 { uint32_t x __attribute__((packed)); };
>> +struct __una_u16 { uint16_t x __attribute__((packed)); };
> 
> Are you sure this actually works ?  I can't see anything in the GCC
> 4.4 docs which requires the compiler to generate special code to
> access such a variable.

Anyway, I think this patch and the preceding one are plain wrong, what
we should do is completely remove the bogus dependence on
asm/unaligned.h, which is a Linux specific header file, and open-code
what we need.

I'm CCing the people that added the LZ4 support to Xen, let's see if
they can shed some light on this.

Roger.

Re: [PATCH RFC 09/23] lz4: add support for OSes that don't have asm/unaligned.h

[Ian Jackson]

Roger Pau Monné writes ("Re: [PATCH RFC 09/23] lz4: add support for OSes that don't have asm/unaligned.h"):
> On 17/04/14 19:00, Ian Jackson wrote:
> > Roger Pau Monne writes ("[PATCH RFC 09/23] lz4: add support for OSes that don't have asm/unaligned.h"):
> >> Add a configure check for asm/unaligned.h presence, and if it's not
> >> available open-code the necessary functions for lz4.
> > 
> > Where did this code come from ?
> 
> This came from the Linux kernel, see:
> 
> http://lxr.free-electrons.com/source/include/asm-generic/unaligned.h?v=2.6.25#L80

I think you should mention this in the commit message.  (Including
mentioning the specific Linux version or changeset the file came
from.)

> Anyway, I think this patch and the preceding one are plain wrong, what
> we should do is completely remove the bogus dependence on
> asm/unaligned.h, which is a Linux specific header file, and open-code
> what we need.
> 
> I'm CCing the people that added the LZ4 support to Xen, let's see if
> they can shed some light on this.

OK.

Thanks,
Ian.

Re: [PATCH RFC 09/23] lz4: add support for OSes that don't have asm/unaligned.h

[Ian Campbell]

On Tue, 2014-04-22 at 16:46 +0200, Roger Pau Monné wrote:
> Anyway, I think this patch and the preceding one are plain wrong, what
> we should do is completely remove the bogus dependence on
> asm/unaligned.h, which is a Linux specific header file, and open-code
> what we need.

Am I right that for libxc's lz4 support we are using the Linux kernel's
built in decompression code, instead of the relevant userspace library
as we do for most other compression algorithms?

> 
> I'm CCing the people that added the LZ4 support to Xen, let's see if
> they can shed some light on this.
> 
> Roger.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 09/23] lz4: add support for OSes that don't have asm/unaligned.h

[Roger Pau Monné]

On 22/04/14 17:55, Ian Campbell wrote:
> On Tue, 2014-04-22 at 16:46 +0200, Roger Pau Monné wrote:
>> Anyway, I think this patch and the preceding one are plain wrong, what
>> we should do is completely remove the bogus dependence on
>> asm/unaligned.h, which is a Linux specific header file, and open-code
>> what we need.
> 
> Am I right that for libxc's lz4 support we are using the Linux kernel's
> built in decompression code, instead of the relevant userspace library
> as we do for most other compression algorithms?

No, I don't think we are using Linux kernel's built in decompression
code, but we are using some non-standard functions, like
__get_unaligned, which are only defined in Linux's asm/unaligned.h.
IMHO, we should get rid of the include of asm/unaligned.h and code
whatever functions we need from that file in a portable way.

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 09/23] lz4: add support for OSes that don't have asm/unaligned.h

[Yann Collet]

[-- Attachment #1.1: Type: text/plain, Size: 2302 bytes --]

Not sure about which version of lz4 source code is used,
so my comment may be out of context,

but for your information,
the C code provided at https://code.google.com/p/lz4/
already handles unaligned access on strict align CPU.

The method is close or the same as the one described into asm/unaligned.h :
typedef struct { U16 v; }  _PACKED U16_S;
typedef struct { U32 v; }  _PACKED U32_S;
typedef struct { U64 v; }  _PACKED U64_S;
typedef struct {size_t v;} _PACKED size_t_S;

but directly integrated into lz4.c source file.

The method rely on the compiler to automatically determine if the target
system requires extra-caution for unaligned access, but sometimes, the
compiler can be over-cautious (typically for ARM target).
Therefore, a manual override is also provided, near the top of the lz4.c
source file :

/*
 * Unaligned memory access is automatically enabled for "common" CPU, such
as x86.
 * For others CPU, such as ARM, the compiler may be more cautious,
inserting unnecessary extra code to ensure aligned access property
 * If you know your target CPU supports unaligned memory access, you want
to force this option manually to improve performance
 */
#if defined(__ARM_FEATURE_UNALIGNED)
#  define LZ4_FORCE_UNALIGNED_ACCESS 1
#endif

Hope it helps.

Regards



2014-04-22 18:40 GMT+02:00 Roger Pau Monné <roger.pau@citrix.com>:

> On 22/04/14 17:55, Ian Campbell wrote:
> > On Tue, 2014-04-22 at 16:46 +0200, Roger Pau Monné wrote:
> >> Anyway, I think this patch and the preceding one are plain wrong, what
> >> we should do is completely remove the bogus dependence on
> >> asm/unaligned.h, which is a Linux specific header file, and open-code
> >> what we need.
> >
> > Am I right that for libxc's lz4 support we are using the Linux kernel's
> > built in decompression code, instead of the relevant userspace library
> > as we do for most other compression algorithms?
>
> No, I don't think we are using Linux kernel's built in decompression
> code, but we are using some non-standard functions, like
> __get_unaligned, which are only defined in Linux's asm/unaligned.h.
> IMHO, we should get rid of the include of asm/unaligned.h and code
> whatever functions we need from that file in a portable way.
>
> Roger.
>
>

[-- Attachment #1.2: Type: text/html, Size: 8447 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 09/23] lz4: add support for OSes that don't have asm/unaligned.h

[Ian Campbell]

On Tue, 2014-04-22 at 18:40 +0200, Roger Pau Monné wrote:
> On 22/04/14 17:55, Ian Campbell wrote:
> > On Tue, 2014-04-22 at 16:46 +0200, Roger Pau Monné wrote:
> >> Anyway, I think this patch and the preceding one are plain wrong, what
> >> we should do is completely remove the bogus dependence on
> >> asm/unaligned.h, which is a Linux specific header file, and open-code
> >> what we need.
> > 
> > Am I right that for libxc's lz4 support we are using the Linux kernel's
> > built in decompression code, instead of the relevant userspace library
> > as we do for most other compression algorithms?
> 
> No, I don't think we are using Linux kernel's built in decompression
> code,

Which library provides lz4_decompress_unknownoutputsize then?

It looks to me like xc_dom_decompress_lz4 gets it from #include
"../../xen/common/lz4/decompress.c" even in the !__MINIOS__ case and:
        $ head -n2 xen/common/lz4/decompress.c
        /*
         * LZ4 Decompressor for Linux kernel

i.e. this is Linux code (which Linux uses to decompress itself on boot)
copied into the hypervisor.

Since this is imported code we don't really want to rewrite it so we can
resync easily in the future. It's up to Xen and libxc to provide the
necessary scaffolding (in terms of helpers the unaligned accessors) to
make this code compile.

>  but we are using some non-standard functions, like
> __get_unaligned, which are only defined in Linux's asm/unaligned.h.
> IMHO, we should get rid of the include of asm/unaligned.h and code
> whatever functions we need from that file in a portable way.
> 
> Roger.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 09/23] lz4: add support for OSes that don't have asm/unaligned.h

[Roger Pau Monné]

On 23/04/14 10:53, Ian Campbell wrote:
> On Tue, 2014-04-22 at 18:40 +0200, Roger Pau Monné wrote:
>> On 22/04/14 17:55, Ian Campbell wrote:
>>> On Tue, 2014-04-22 at 16:46 +0200, Roger Pau Monné wrote:
>>>> Anyway, I think this patch and the preceding one are plain wrong, what
>>>> we should do is completely remove the bogus dependence on
>>>> asm/unaligned.h, which is a Linux specific header file, and open-code
>>>> what we need.
>>>
>>> Am I right that for libxc's lz4 support we are using the Linux kernel's
>>> built in decompression code, instead of the relevant userspace library
>>> as we do for most other compression algorithms?
>>
>> No, I don't think we are using Linux kernel's built in decompression
>> code,
> 
> Which library provides lz4_decompress_unknownoutputsize then?
> 
> It looks to me like xc_dom_decompress_lz4 gets it from #include
> "../../xen/common/lz4/decompress.c" even in the !__MINIOS__ case and:
>         $ head -n2 xen/common/lz4/decompress.c
>         /*
>          * LZ4 Decompressor for Linux kernel
> 
> i.e. this is Linux code (which Linux uses to decompress itself on boot)
> copied into the hypervisor.
> 
> Since this is imported code we don't really want to rewrite it so we can
> resync easily in the future. It's up to Xen and libxc to provide the
> necessary scaffolding (in terms of helpers the unaligned accessors) to
> make this code compile.

Yes, sorry I misunderstood you, I though you were saying that somehow
Xen (or the tools), were relying on the Linux kernel to perform the
decompression (which makes no sense).

That's my plan, but instead of adding some crappy hack for OSes that
don't have asm/unaligned.h, I would like to get rid of that dependency
and code the helpers that we need.

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 09/23] lz4: add support for OSes that don't have asm/unaligned.h

[Ian Campbell]

On Wed, 2014-04-23 at 11:06 +0200, Roger Pau Monné wrote:
> On 23/04/14 10:53, Ian Campbell wrote:
> > On Tue, 2014-04-22 at 18:40 +0200, Roger Pau Monné wrote:
> >> On 22/04/14 17:55, Ian Campbell wrote:
> >>> On Tue, 2014-04-22 at 16:46 +0200, Roger Pau Monné wrote:
> >>>> Anyway, I think this patch and the preceding one are plain wrong, what
> >>>> we should do is completely remove the bogus dependence on
> >>>> asm/unaligned.h, which is a Linux specific header file, and open-code
> >>>> what we need.
> >>>
> >>> Am I right that for libxc's lz4 support we are using the Linux kernel's
> >>> built in decompression code, instead of the relevant userspace library
> >>> as we do for most other compression algorithms?
> >>
> >> No, I don't think we are using Linux kernel's built in decompression
> >> code,
> > 
> > Which library provides lz4_decompress_unknownoutputsize then?
> > 
> > It looks to me like xc_dom_decompress_lz4 gets it from #include
> > "../../xen/common/lz4/decompress.c" even in the !__MINIOS__ case and:
> >         $ head -n2 xen/common/lz4/decompress.c
> >         /*
> >          * LZ4 Decompressor for Linux kernel
> > 
> > i.e. this is Linux code (which Linux uses to decompress itself on boot)
> > copied into the hypervisor.
> > 
> > Since this is imported code we don't really want to rewrite it so we can
> > resync easily in the future. It's up to Xen and libxc to provide the
> > necessary scaffolding (in terms of helpers the unaligned accessors) to
> > make this code compile.
> 
> Yes, sorry I misunderstood you, I though you were saying that somehow
> Xen (or the tools), were relying on the Linux kernel to perform the
> decompression

Ah yes, I can see how that was confusing, sorry!

>  (which makes no sense).

Indeed.

> That's my plan, but instead of adding some crappy hack for OSes that
> don't have asm/unaligned.h, I would like to get rid of that dependency
> and code the helpers that we need.

In the scaffolding and not by modifying the imported code I pressume? In
which case, good thanks!

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 09/23] lz4: add support for OSes that don't have asm/unaligned.h

[Roger Pau Monné]

On 23/04/14 11:09, Ian Campbell wrote:
> On Wed, 2014-04-23 at 11:06 +0200, Roger Pau Monné wrote:
>> On 23/04/14 10:53, Ian Campbell wrote:
>>> On Tue, 2014-04-22 at 18:40 +0200, Roger Pau Monné wrote:
>>>> On 22/04/14 17:55, Ian Campbell wrote:
>>>>> On Tue, 2014-04-22 at 16:46 +0200, Roger Pau Monné wrote:
>>>>>> Anyway, I think this patch and the preceding one are plain wrong, what
>>>>>> we should do is completely remove the bogus dependence on
>>>>>> asm/unaligned.h, which is a Linux specific header file, and open-code
>>>>>> what we need.
>>>>>
>>>>> Am I right that for libxc's lz4 support we are using the Linux kernel's
>>>>> built in decompression code, instead of the relevant userspace library
>>>>> as we do for most other compression algorithms?
>>>>
>>>> No, I don't think we are using Linux kernel's built in decompression
>>>> code,
>>>
>>> Which library provides lz4_decompress_unknownoutputsize then?
>>>
>>> It looks to me like xc_dom_decompress_lz4 gets it from #include
>>> "../../xen/common/lz4/decompress.c" even in the !__MINIOS__ case and:
>>>         $ head -n2 xen/common/lz4/decompress.c
>>>         /*
>>>          * LZ4 Decompressor for Linux kernel
>>>
>>> i.e. this is Linux code (which Linux uses to decompress itself on boot)
>>> copied into the hypervisor.
>>>
>>> Since this is imported code we don't really want to rewrite it so we can
>>> resync easily in the future. It's up to Xen and libxc to provide the
>>> necessary scaffolding (in terms of helpers the unaligned accessors) to
>>> make this code compile.
>>
>> Yes, sorry I misunderstood you, I though you were saying that somehow
>> Xen (or the tools), were relying on the Linux kernel to perform the
>> decompression
> 
> Ah yes, I can see how that was confusing, sorry!
> 
>>  (which makes no sense).
> 
> Indeed.
> 
>> That's my plan, but instead of adding some crappy hack for OSes that
>> don't have asm/unaligned.h, I would like to get rid of that dependency
>> and code the helpers that we need.
> 
> In the scaffolding and not by modifying the imported code I pressume? In
> which case, good thanks!

While working around this issue, I've noticed that xen/common/lz4/defs.h
has one branch for little endian and another one for big endian, but
while compiling libxc, "__LITTLE_ENDIAN" is not defined and we fall into
big endian, which seems wrong, because we don't have support for any big
endian arch.

Would it be OK to get rid of the big endian case, and only support
little endian by default?

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 09/23] lz4: add support for OSes that don't have asm/unaligned.h

[Ian Campbell]

On Wed, 2014-04-23 at 18:18 +0200, Roger Pau Monné wrote:

> > In the scaffolding and not by modifying the imported code I pressume? In
> > which case, good thanks!
> 
> While working around this issue, I've noticed that xen/common/lz4/defs.h
> has one branch for little endian and another one for big endian, but
> while compiling libxc, "__LITTLE_ENDIAN" is not defined and we fall into
> big endian, which seems wrong, because we don't have support for any big
> endian arch.
> 
> Would it be OK to get rid of the big endian case, and only support
> little endian by default?

I think it would be better to #define __LITTLE_ENDIAN than to diverge
from the upstream of this file.

gcc has some built #defines for this see [0], but I'd have thought this
would be something autoconf could assist with. Or we could probably get
away with a static #define in tools/libxc/xc_dom_decompress_lz4.c.

Ian.

[0] http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html#Common-Predefined-Macros

          /* Test for a little-endian machine */
          #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__     
> 
> Roger.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 09/23] lz4: add support for OSes that don't have asm/unaligned.h

[Roger Pau Monné]

On 24/04/14 10:28, Ian Campbell wrote:
> On Wed, 2014-04-23 at 18:18 +0200, Roger Pau Monné wrote:
> 
>>> In the scaffolding and not by modifying the imported code I pressume? In
>>> which case, good thanks!
>>
>> While working around this issue, I've noticed that xen/common/lz4/defs.h
>> has one branch for little endian and another one for big endian, but
>> while compiling libxc, "__LITTLE_ENDIAN" is not defined and we fall into
>> big endian, which seems wrong, because we don't have support for any big
>> endian arch.
>>
>> Would it be OK to get rid of the big endian case, and only support
>> little endian by default?
> 
> I think it would be better to #define __LITTLE_ENDIAN than to diverge
> from the upstream of this file.

We have already diverged from upstream by adding those __LITTLE_ENDIAN 
checks, the upstream file doesn't seem to contain them in any of the 
versions:

http://lxr.free-electrons.com/source/lib/lz4/lz4defs.h

The following patch removes this cruft, but I'm unsure if we want to 
keep this endianness differentiation:

diff --git a/tools/libxc/xc_dom_decompress_lz4.c b/tools/libxc/xc_dom_decompress_lz4.c
index 08272fe..490ec56 100644
--- a/tools/libxc/xc_dom_decompress_lz4.c
+++ b/tools/libxc/xc_dom_decompress_lz4.c
@@ -1,7 +1,6 @@
 #include <stdio.h>
 #include <stdlib.h>
 #include <inttypes.h>
-#include <endian.h>
 #include <stdint.h>
 
 #include "xg_private.h"
diff --git a/xen/common/lz4/defs.h b/xen/common/lz4/defs.h
index f46df08..d886a4e 100644
--- a/xen/common/lz4/defs.h
+++ b/xen/common/lz4/defs.h
@@ -12,7 +12,6 @@
 #include <asm/byteorder.h>
 #endif
 
-#ifdef __LITTLE_ENDIAN
 static inline u16 INIT get_unaligned_le16(const void *p)
 {
 	return le16_to_cpup(p);
@@ -22,19 +21,6 @@ static inline u32 INIT get_unaligned_le32(const void *p)
 {
 	return le32_to_cpup(p);
 }
-#else
-#include <asm/unaligned.h>
-
-static inline u16 INIT get_unaligned_le16(const void *p)
-{
-	return le16_to_cpu(__get_unaligned(p, 2));
-}
-
-static inline u32 INIT get_unaligned_le32(void *p)
-{
-	return le32_to_cpu(__get_unaligned(p, 4));
-}
-#endif
 
 /*
  * Detects 64 bits mode


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 09/23] lz4: add support for OSes that don't have asm/unaligned.h

[Ian Campbell]

On Thu, 2014-04-24 at 11:19 +0200, Roger Pau Monné wrote:
> On 24/04/14 10:28, Ian Campbell wrote:
> > On Wed, 2014-04-23 at 18:18 +0200, Roger Pau Monné wrote:
> > 
> >>> In the scaffolding and not by modifying the imported code I pressume? In
> >>> which case, good thanks!
> >>
> >> While working around this issue, I've noticed that xen/common/lz4/defs.h
> >> has one branch for little endian and another one for big endian, but
> >> while compiling libxc, "__LITTLE_ENDIAN" is not defined and we fall into
> >> big endian, which seems wrong, because we don't have support for any big
> >> endian arch.
> >>
> >> Would it be OK to get rid of the big endian case, and only support
> >> little endian by default?
> > 
> > I think it would be better to #define __LITTLE_ENDIAN than to diverge
> > from the upstream of this file.
> 
> We have already diverged from upstream by adding those __LITTLE_ENDIAN 
> checks, the upstream file doesn't seem to contain them in any of the 
> versions:
> 
> http://lxr.free-electrons.com/source/lib/lz4/lz4defs.h

Ah, those blocks are part of our shimming to make things work (i.e.
trying and failing to do what I was suggesting).

Actually the two cases are pretty weird. they differ only in their use
of the unaligned macros for big endian -- which seems rather orthogonal
to the test for __LITTLE_ENDIAN.

> The following patch removes this cruft, but I'm unsure if we want to 
> keep this endianness differentiation:

I think this would be ok, if the alignedness really matters then that
should be what is tested for I think...


> 
> diff --git a/tools/libxc/xc_dom_decompress_lz4.c b/tools/libxc/xc_dom_decompress_lz4.c
> index 08272fe..490ec56 100644
> --- a/tools/libxc/xc_dom_decompress_lz4.c
> +++ b/tools/libxc/xc_dom_decompress_lz4.c
> @@ -1,7 +1,6 @@
>  #include <stdio.h>
>  #include <stdlib.h>
>  #include <inttypes.h>
> -#include <endian.h>
>  #include <stdint.h>
>  
>  #include "xg_private.h"
> diff --git a/xen/common/lz4/defs.h b/xen/common/lz4/defs.h
> index f46df08..d886a4e 100644
> --- a/xen/common/lz4/defs.h
> +++ b/xen/common/lz4/defs.h
> @@ -12,7 +12,6 @@
>  #include <asm/byteorder.h>
>  #endif
>  
> -#ifdef __LITTLE_ENDIAN
>  static inline u16 INIT get_unaligned_le16(const void *p)
>  {
>  	return le16_to_cpup(p);
> @@ -22,19 +21,6 @@ static inline u32 INIT get_unaligned_le32(const void *p)
>  {
>  	return le32_to_cpup(p);
>  }
> -#else
> -#include <asm/unaligned.h>
> -
> -static inline u16 INIT get_unaligned_le16(const void *p)
> -{
> -	return le16_to_cpu(__get_unaligned(p, 2));
> -}
> -
> -static inline u32 INIT get_unaligned_le32(void *p)
> -{
> -	return le32_to_cpu(__get_unaligned(p, 4));
> -}
> -#endif
>  
>  /*
>   * Detects 64 bits mode
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[PATCH RFC 10/23] xenstored: add the FreeBSD xenstored interface

[Roger Pau Monne]

This patch adds FreeBSD support to xenstored, by implementing the
FreeBSD interface to /dev/xen/xenstored.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/Makefile            |    1 +
 tools/xenstore/xenstored_freebsd.c |   72 ++++++++++++++++++++++++++++++++++++
 tools/xenstore/xs_lib.c            |    2 +
 3 files changed, 75 insertions(+), 0 deletions(-)
 create mode 100644 tools/xenstore/xenstored_freebsd.c

diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 262f401..0b2b2c7 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -14,6 +14,7 @@ CLIENTS += xenstore-write xenstore-ls xenstore-watch
 XENSTORED_OBJS = xenstored_core.o xenstored_watch.o xenstored_domain.o xenstored_transaction.o xs_lib.o talloc.o utils.o tdb.o hashtable.o
 
 XENSTORED_OBJS_$(CONFIG_Linux) = xenstored_linux.o xenstored_posix.o
+XENSTORED_OBJS_$(CONFIG_FreeBSD) = xenstored_freebsd.o xenstored_posix.o
 XENSTORED_OBJS_$(CONFIG_SunOS) = xenstored_solaris.o xenstored_posix.o xenstored_probes.o
 XENSTORED_OBJS_$(CONFIG_NetBSD) = xenstored_netbsd.o xenstored_posix.o
 XENSTORED_OBJS_$(CONFIG_MiniOS) = xenstored_minios.o
diff --git a/tools/xenstore/xenstored_freebsd.c b/tools/xenstore/xenstored_freebsd.c
new file mode 100644
index 0000000..f4e5fc2
--- /dev/null
+++ b/tools/xenstore/xenstored_freebsd.c
@@ -0,0 +1,72 @@
+/******************************************************************************
+ *
+ * Copyright 2006 Sun Microsystems, Inc.  All rights reserved.
+ * Use is subject to license terms.
+ *
+ * Copyright (C) 2005 Rusty Russell IBM Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2 of the
+ * License.
+ */
+
+#include <fcntl.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <sys/mman.h>
+
+#include "xenstored_core.h"
+
+#define XENSTORED_DEV  "/dev/xen/xenstored"
+
+evtchn_port_t xenbus_evtchn(void)
+{
+	int fd;
+	int rc;
+	evtchn_port_t port;
+	char str[20];
+
+	fd = open(XENSTORED_DEV, O_RDONLY);
+	if (fd == -1)
+		return -1;
+
+	rc = read(fd, str, sizeof(str) - 1);
+	if (rc == -1)
+	{
+		int err = errno;
+		close(fd);
+		errno = err;
+		return -1;
+	}
+
+	str[rc] = '\0';
+	port = strtoul(str, NULL, 0);
+
+	close(fd);
+	return port;
+}
+
+void *xenbus_map(void)
+{
+	int fd;
+	void *addr;
+
+	fd = open(XENSTORED_DEV, O_RDWR);
+	if (fd == -1)
+		return NULL;
+
+	addr = mmap(NULL, getpagesize(), PROT_READ|PROT_WRITE,
+		MAP_SHARED, fd, 0);
+
+	if (addr == MAP_FAILED)
+		addr = NULL;
+
+	close(fd);
+
+	return addr;
+}
+
+void xenbus_notify_running(void)
+{
+}
diff --git a/tools/xenstore/xs_lib.c b/tools/xenstore/xs_lib.c
index f7076cc..dfbeff1 100644
--- a/tools/xenstore/xs_lib.c
+++ b/tools/xenstore/xs_lib.c
@@ -84,6 +84,8 @@ const char *xs_domain_dev(void)
 	return "/proc/xen/xenbus";
 #elif defined(__NetBSD__)
 	return "/kern/xen/xenbus";
+#elif defined(__FreeBSD__)
+	return "/dev/xen/xenstore";
 #else
 	return "/dev/xen/xenbus";
 #endif
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 10/23] xenstored: add the FreeBSD xenstored interface

[Ian Jackson]

Roger Pau Monne writes ("[PATCH RFC 10/23] xenstored: add the FreeBSD xenstored interface"):
> This patch adds FreeBSD support to xenstored, by implementing the
> FreeBSD interface to /dev/xen/xenstored.

Again, this is very similar to xenstored_linux.c.  As is
xenstored_netbsd.c :-/.

TBH I'm not sure it's fair to ask you to drain this swamp as part of
sending in a new port...

Ian.

Re: [PATCH RFC 10/23] xenstored: add the FreeBSD xenstored interface

[Roger Pau Monné]

On 17/04/14 19:02, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH RFC 10/23] xenstored: add the FreeBSD xenstored interface"):
>> This patch adds FreeBSD support to xenstored, by implementing the
>> FreeBSD interface to /dev/xen/xenstored.
> 
> Again, this is very similar to xenstored_linux.c.  As is
> xenstored_netbsd.c :-/.

Yes, the main difference is that both Linux and NetBSD seem to use two
different devices in order to get the evtchn port and to map xenstored
memory. On the other hand, FreeBSD uses the same device in order to
obtain the port and do the mmap.

IMHO all this implementations could be easily folded into a single file
with very little ifdefery, I will take a look at it.

Roger.

Re: [PATCH RFC 10/23] xenstored: add the FreeBSD xenstored interface

[Ian Jackson]

Roger Pau Monné writes ("Re: [PATCH RFC 10/23] xenstored: add the FreeBSD xenstored interface"):
> IMHO all this implementations could be easily folded into a single file
> with very little ifdefery, I will take a look at it.

That would be excellent, thank you.

Ian.

[PATCH RFC 11/23] xenstore: add some missing headers

[Roger Pau Monne]

xs_tdb_dump.c was including tdb.h, which makes use of dev_t and ino_t,
which are defined in sys/types.h.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/xs_tdb_dump.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/xs_tdb_dump.c b/tools/xenstore/xs_tdb_dump.c
index 7aa7158..b91cdef 100644
--- a/tools/xenstore/xs_tdb_dump.c
+++ b/tools/xenstore/xs_tdb_dump.c
@@ -5,6 +5,7 @@
 #include <stdio.h>
 #include <stdarg.h>
 #include <string.h>
+#include <sys/types.h>
 #include "xenstore_lib.h"
 #include "tdb.h"
 #include "talloc.h"
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[PATCH RFC 11/23] xenstore: add some missing headers

[Ian Jackson]

Roger Pau Monne writes ("[PATCH RFC 11/23] xenstore: add some missing headers"):
> xs_tdb_dump.c was including tdb.h, which makes use of dev_t and ino_t,
> which are defined in sys/types.h.

I was going to say "can't we put this in tdb.h" but after looking at
tdb.h I see why you didn't want to do that :-/.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

[PATCH RFC 12/23] console: add FreeBSD includes

[Roger Pau Monne]

Add FreeBSD specific includes to the console daemon.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/console/daemon/io.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 007ecf4..255a6a3 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -43,6 +43,11 @@
 #include <pty.h>
 #elif defined(__sun__)
 #include <stropts.h>
+#elif defined(__FreeBSD__)
+#include <sys/types.h>
+#include <sys/ioctl.h>
+#include <termios.h>
+#include <libutil.h>
 #endif
 
 #define MAX(a, b) (((a) > (b)) ? (a) : (b))
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 12/23] console: add FreeBSD includes

[Ian Jackson]

Roger Pau Monne writes ("[PATCH RFC 12/23] console: add FreeBSD includes"):
> Add FreeBSD specific includes to the console daemon.
...
>  #include <stropts.h>
> +#elif defined(__FreeBSD__)
> +#include <sys/types.h>
> +#include <sys/ioctl.h>
> +#include <termios.h>
> +#include <libutil.h>
>  #endif

<termios.h> is already there earlier.  <sys/types.h> can probably be
outside the #ifdef.

Ian.

[PATCH RFC 13/23] init: add FreeBSD xencommons init script

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/hotplug/FreeBSD/Makefile        |   43 ++++++++++++
 tools/hotplug/FreeBSD/rc.d/xencommons |  121 +++++++++++++++++++++++++++++++++
 tools/hotplug/Makefile                |    1 +
 3 files changed, 165 insertions(+), 0 deletions(-)
 create mode 100644 tools/hotplug/FreeBSD/Makefile
 create mode 100644 tools/hotplug/FreeBSD/rc.d/xencommons

diff --git a/tools/hotplug/FreeBSD/Makefile b/tools/hotplug/FreeBSD/Makefile
new file mode 100644
index 0000000..c7ffc51
--- /dev/null
+++ b/tools/hotplug/FreeBSD/Makefile
@@ -0,0 +1,43 @@
+XEN_ROOT = $(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+# Xen script dir and scripts to go there.
+XEN_SCRIPTS =
+
+XEN_SCRIPT_DATA =
+
+XEN_RCD_PROG = rc.d/xencommons
+
+.PHONY: all
+all:
+
+.PHONY: build
+build:
+
+.PHONY: install
+install: all install-scripts install-rcd
+
+.PHONY: install-scripts
+install-scripts:
+	$(INSTALL_DIR) $(DESTDIR)$(XEN_SCRIPT_DIR)
+	set -e; for i in $(XEN_SCRIPTS); \
+	   do \
+	   $(INSTALL_PROG) $$i $(DESTDIR)$(XEN_SCRIPT_DIR); \
+	done
+	set -e; for i in $(XEN_SCRIPT_DATA); \
+	   do \
+	   $(INSTALL_DATA) $$i $(DESTDIR)$(XEN_SCRIPT_DIR); \
+	done
+
+.PHONY: install-rcd
+install-rcd:
+	$(INSTALL_DIR) $(DESTDIR)$(CONFIG_DIR)/rc.d
+	set -e; for i in $(XEN_RCD_PROG); \
+	   do \
+	   $(INSTALL_PROG) $$i $(DESTDIR)$(CONFIG_DIR)/rc.d; \
+	   sed -i '' 's,@xen_script_dir@,$(DESTDIR)$(XEN_SCRIPT_DIR),g' $(DESTDIR)$(CONFIG_DIR)/$$i; \
+	done
+	$(INSTALL_DATA) ../common/hotplugpath.sh $(DESTDIR)$(XEN_SCRIPT_DIR)
+
+.PHONY: clean
+clean:
diff --git a/tools/hotplug/FreeBSD/rc.d/xencommons b/tools/hotplug/FreeBSD/rc.d/xencommons
new file mode 100644
index 0000000..a797016
--- /dev/null
+++ b/tools/hotplug/FreeBSD/rc.d/xencommons
@@ -0,0 +1,121 @@
+#!/bin/sh
+#
+# PROVIDE: xencommons
+# REQUIRE: DAEMON
+
+. /etc/rc.subr
+
+. @xen_script_dir@/hotplugpath.sh
+
+LD_LIBRARY_PATH="${LIBDIR}"
+export LD_LIBRARY_PATH
+
+name="xencommons"
+start_precmd="xen_precmd"
+start_cmd="xen_startcmd"
+stop_cmd="xen_stop"
+status_cmd="xen_status"
+extra_commands="status"
+required_files="/dev/xen/privcmd"
+
+XENSTORED_PIDFILE="/var/run/xenstored.pid"
+XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
+#XENCONSOLED_TRACE="/var/log/xen/xenconsole-trace.log"
+#XENSTORED_TRACE="/var/log/xen/xenstore-trace.log"
+
+xen_precmd()
+{
+	mkdir -p /var/run/xenstored || exit 1
+}
+
+xen_startcmd()
+{
+	local time=0
+	local timeout=30
+
+	xenstored_pid=$(check_pidfile ${XENSTORED_PIDFILE} ${SBINDIR}/xenstored)
+	if test -z "$xenstored_pid"; then
+		printf "Cleaning xenstore database.\n"
+		if [ -z "${XENSTORED_ROOTDIR}" ]; then
+			XENSTORED_ROOTDIR="/var/lib/xenstored"
+		fi
+		rm -f ${XENSTORED_ROOTDIR}/tdb* >/dev/null 2>&1
+		printf "Starting xenservices: xenstored, xenconsoled."
+		XENSTORED_ARGS=" --pid-file ${XENSTORED_PIDFILE}"
+		if [ -n "${XENSTORED_TRACE}" ]; then
+			XENSTORED_ARGS="${XENSTORED_ARGS} -T /var/log/xen/xenstored-trace.log"
+		fi
+		${SBINDIR}/xenstored ${XENSTORED_ARGS}
+		while [ $time -lt $timeout ] && ! `${BINDIR}/xenstore-read -s / >/dev/null 2>&1` ; do
+			printf "."
+			time=$(($time+1))
+			sleep 1
+		done
+	else
+		printf "Starting xenservices: xenconsoled."
+	fi
+
+	XENCONSOLED_ARGS=""
+	if [ -n "${XENCONSOLED_TRACE}" ]; then
+		XENCONSOLED_ARGS="${XENCONSOLED_ARGS} --log=${XENCONSOLED_TRACE}"
+	fi
+
+	${SBINDIR}/xenconsoled ${XENCONSOLED_ARGS}
+
+	printf "\n"
+
+	printf "Setting domain 0 name and domid.\n"
+	${BINDIR}/xenstore-write "/local/domain/0/name" "Domain-0"
+	${BINDIR}/xenstore-write "/local/domain/0/domid" 0
+}
+
+xen_stop()
+{
+	pids=""
+	printf "Stopping xencommons.\n"
+	printf "WARNING: Not stopping xenstored, as it cannot be restarted.\n"
+
+	rc_pid=$(check_pidfile ${XENCONSOLED_PIDFILE} ${SBINDIR}/xenconsoled)
+	pids="$pids $rc_pid"
+
+	kill -${sig_stop:-TERM} $pids
+	wait_for_pids $pids
+}
+
+xen_status()
+{
+	xenstored_pid=$(check_pidfile ${XENSTORED_PIDFILE} ${SBINDIR}/xenstored)
+	if test -n ${xenstored_pid}; then
+		pids="$pids $xenstored_pid"
+	fi
+
+	xenconsoled_pid=$(check_pidfile ${XENCONSOLED_PIDFILE} ${SBINDIR}/xenconsoled)
+	if test -n ${xenconsoled_pid}; then
+		pids="$pids $xenconsoled_pid"
+	fi
+
+	if test -n "$xenconsoled_pid" -a -n "$xenstored_pid";
+	then
+		echo "xencommons are running as pids $pids."
+		return 0
+	fi
+	if test -z "$xenconsoled_pid" -a -z "$xenstored_pid";
+	then
+		echo "xencommons are not running."
+		return 0
+	fi
+
+	if test -n $xenstored_pid; then
+		echo "xenstored is running as pid $xenstored_pid."
+	else
+		echo "xenstored is not running."
+	fi
+	if test -n $xenconsoled_pid; then
+		echo "xenconsoled is running as pid $xenconsoled_pid."
+	else
+		echo "xenconsoled is not running."
+	fi
+}
+
+load_rc_config $name
+run_rc_command "$1"
diff --git a/tools/hotplug/Makefile b/tools/hotplug/Makefile
index f147b59..14ae9a8 100644
--- a/tools/hotplug/Makefile
+++ b/tools/hotplug/Makefile
@@ -4,6 +4,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 SUBDIRS-y := common
 SUBDIRS-$(CONFIG_NetBSD) += NetBSD
 SUBDIRS-$(CONFIG_Linux) += Linux
+SUBDIRS-$(CONFIG_FreeBSD) += FreeBSD
 
 .PHONY: all clean install
 all clean install: %: subdirs-%
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 13/23] init: add FreeBSD xencommons init script

[Ian Campbell]

On Wed, 2014-04-16 at 16:13 +0200, Roger Pau Monne wrote:

Is this new or a clone of NetBSD?

Re: [PATCH RFC 13/23] init: add FreeBSD xencommons init script

[Roger Pau Monné]

On 28/04/14 16:36, Ian Campbell wrote:
> On Wed, 2014-04-16 at 16:13 +0200, Roger Pau Monne wrote:
> 
> Is this new or a clone of NetBSD?

It's pretty much a clone of the NetBSD one, with some very minor
modifications.

Roger.

Re: [PATCH RFC 13/23] init: add FreeBSD xencommons init script

[Ian Campbell]

On Mon, 2014-06-02 at 13:53 +0200, Roger Pau Monné wrote:
> On 28/04/14 16:36, Ian Campbell wrote:
> > On Wed, 2014-04-16 at 16:13 +0200, Roger Pau Monne wrote:
> > 
> > Is this new or a clone of NetBSD?
> 
> It's pretty much a clone of the NetBSD one, with some very minor
> modifications.

OK, then I shan't bother to read it too closely, can you mention the
provenance in the commit log though please.

This duplication is unfortunate but there is lots of similar duplication
already and I don't think we can expect you to drain that swamp as part
of this series.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[PATCH RFC 14/23] hotplug: add FreeBSD vif-bridge

[Roger Pau Monne]

Add a simple vif-bridge script, that takes care of adding network
backends (tap or xnb) to a pre-configured bridge.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/hotplug/FreeBSD/Makefile   |    2 +-
 tools/hotplug/FreeBSD/vif-bridge |   41 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 42 insertions(+), 1 deletions(-)
 create mode 100644 tools/hotplug/FreeBSD/vif-bridge

diff --git a/tools/hotplug/FreeBSD/Makefile b/tools/hotplug/FreeBSD/Makefile
index c7ffc51..6480aa5 100644
--- a/tools/hotplug/FreeBSD/Makefile
+++ b/tools/hotplug/FreeBSD/Makefile
@@ -2,7 +2,7 @@ XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 # Xen script dir and scripts to go there.
-XEN_SCRIPTS =
+XEN_SCRIPTS = vif-bridge
 
 XEN_SCRIPT_DATA =
 
diff --git a/tools/hotplug/FreeBSD/vif-bridge b/tools/hotplug/FreeBSD/vif-bridge
new file mode 100644
index 0000000..b36d075
--- /dev/null
+++ b/tools/hotplug/FreeBSD/vif-bridge
@@ -0,0 +1,41 @@
+#!/bin/sh -e
+#
+# FreeBSD hotplug script for attaching xnb* interfaces to bridges
+#
+# Parameters:
+#	$1: xenstore backend path of the vif
+#	$2: action, either "add" or "remove"
+#
+# Environment variables:
+#	$iface_dev: name of the backend device (xnb<domid>.<handle>)
+#
+
+DIR=$(dirname "$0")
+. "${DIR}/hotplugpath.sh"
+
+PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${PRIVATE_BINDIR}:/bin:/usr/bin:/sbin:/usr/sbin
+export PATH
+
+xpath=$1
+xaction=$2
+
+case $xaction in
+add)
+	xbridge=$(xenstore-read "$xpath/bridge")
+	ifconfig $xbridge addm $iface_dev
+	ifconfig $iface_dev up
+	exit 0
+	;;
+remove)
+	if [ "$emulated" -eq 1 ]; then
+		xbridge=$(xenstore-read "$xpath/bridge")
+		ifconfig $iface_dev down
+		ifconfig $xbridge deletem $iface_dev
+		ifconfig $iface_dev destroy
+	fi
+	exit 0
+	;;
+*)
+	exit 0
+	;;
+esac
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 14/23] hotplug: add FreeBSD vif-bridge

[Ian Campbell]

On Wed, 2014-04-16 at 16:13 +0200, Roger Pau Monne wrote:
> Add a simple vif-bridge script, that takes care of adding network
> backends (tap or xnb) to a pre-configured bridge.

Compared with the Linux one it lacks the handling of the vifname
property and the attempt to provide a default if no bridge was
specified. This is probably acceptable I suppose.

> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> ---
>  tools/hotplug/FreeBSD/Makefile   |    2 +-
>  tools/hotplug/FreeBSD/vif-bridge |   41 ++++++++++++++++++++++++++++++++++++++
>  2 files changed, 42 insertions(+), 1 deletions(-)
>  create mode 100644 tools/hotplug/FreeBSD/vif-bridge
> 
> diff --git a/tools/hotplug/FreeBSD/Makefile b/tools/hotplug/FreeBSD/Makefile
> index c7ffc51..6480aa5 100644
> --- a/tools/hotplug/FreeBSD/Makefile
> +++ b/tools/hotplug/FreeBSD/Makefile
> @@ -2,7 +2,7 @@ XEN_ROOT = $(CURDIR)/../../..
>  include $(XEN_ROOT)/tools/Rules.mk
>  
>  # Xen script dir and scripts to go there.
> -XEN_SCRIPTS =
> +XEN_SCRIPTS = vif-bridge
>  
>  XEN_SCRIPT_DATA =
>  
> diff --git a/tools/hotplug/FreeBSD/vif-bridge b/tools/hotplug/FreeBSD/vif-bridge
> new file mode 100644
> index 0000000..b36d075
> --- /dev/null
> +++ b/tools/hotplug/FreeBSD/vif-bridge
> @@ -0,0 +1,41 @@
> +#!/bin/sh -e
> +#
> +# FreeBSD hotplug script for attaching xnb* interfaces to bridges
> +#
> +# Parameters:
> +#	$1: xenstore backend path of the vif
> +#	$2: action, either "add" or "remove"
> +#
> +# Environment variables:
> +#	$iface_dev: name of the backend device (xnb<domid>.<handle>)
> +#
> +
> +DIR=$(dirname "$0")
> +. "${DIR}/hotplugpath.sh"
> +
> +PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${PRIVATE_BINDIR}:/bin:/usr/bin:/sbin:/usr/sbin
> +export PATH
> +
> +xpath=$1
> +xaction=$2

OOI why the x prefixes everywhere?

> +
> +case $xaction in
> +add)
> +	xbridge=$(xenstore-read "$xpath/bridge")
> +	ifconfig $xbridge addm $iface_dev
> +	ifconfig $iface_dev up
> +	exit 0
> +	;;
> +remove)
> +	if [ "$emulated" -eq 1 ]; then
> +		xbridge=$(xenstore-read "$xpath/bridge")
> +		ifconfig $iface_dev down
> +		ifconfig $xbridge deletem $iface_dev
> +		ifconfig $iface_dev destroy
> +	fi
> +	exit 0
> +	;;
> +*)
> +	exit 0
> +	;;
> +esac



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 14/23] hotplug: add FreeBSD vif-bridge

[Roger Pau Monné]

On 28/04/14 16:39, Ian Campbell wrote:
> On Wed, 2014-04-16 at 16:13 +0200, Roger Pau Monne wrote:
>> Add a simple vif-bridge script, that takes care of adding network
>> backends (tap or xnb) to a pre-configured bridge.
> 
> Compared with the Linux one it lacks the handling of the vifname
> property and the attempt to provide a default if no bridge was
> specified. This is probably acceptable I suppose.

I would like to explicitly avoid providing a default bridge if no bridge
was specified, I think this should probably be done in the global xl
configuration file.

>>
>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
>> Cc: Ian Campbell <ian.campbell@citrix.com>
>> ---
>>  tools/hotplug/FreeBSD/Makefile   |    2 +-
>>  tools/hotplug/FreeBSD/vif-bridge |   41 ++++++++++++++++++++++++++++++++++++++
>>  2 files changed, 42 insertions(+), 1 deletions(-)
>>  create mode 100644 tools/hotplug/FreeBSD/vif-bridge
>>
>> diff --git a/tools/hotplug/FreeBSD/Makefile b/tools/hotplug/FreeBSD/Makefile
>> index c7ffc51..6480aa5 100644
>> --- a/tools/hotplug/FreeBSD/Makefile
>> +++ b/tools/hotplug/FreeBSD/Makefile
>> @@ -2,7 +2,7 @@ XEN_ROOT = $(CURDIR)/../../..
>>  include $(XEN_ROOT)/tools/Rules.mk
>>  
>>  # Xen script dir and scripts to go there.
>> -XEN_SCRIPTS =
>> +XEN_SCRIPTS = vif-bridge
>>  
>>  XEN_SCRIPT_DATA =
>>  
>> diff --git a/tools/hotplug/FreeBSD/vif-bridge b/tools/hotplug/FreeBSD/vif-bridge
>> new file mode 100644
>> index 0000000..b36d075
>> --- /dev/null
>> +++ b/tools/hotplug/FreeBSD/vif-bridge
>> @@ -0,0 +1,41 @@
>> +#!/bin/sh -e
>> +#
>> +# FreeBSD hotplug script for attaching xnb* interfaces to bridges
>> +#
>> +# Parameters:
>> +#	$1: xenstore backend path of the vif
>> +#	$2: action, either "add" or "remove"
>> +#
>> +# Environment variables:
>> +#	$iface_dev: name of the backend device (xnb<domid>.<handle>)
>> +#
>> +
>> +DIR=$(dirname "$0")
>> +. "${DIR}/hotplugpath.sh"
>> +
>> +PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${PRIVATE_BINDIR}:/bin:/usr/bin:/sbin:/usr/sbin
>> +export PATH
>> +
>> +xpath=$1
>> +xaction=$2
> 
> OOI why the x prefixes everywhere?

Because they were there on the NetBSD version, but I will remove them in
the next version of the series.

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 14/23] hotplug: add FreeBSD vif-bridge

[Ian Campbell]

On Mon, 2014-06-02 at 13:56 +0200, Roger Pau Monné wrote:
> On 28/04/14 16:39, Ian Campbell wrote:
> > On Wed, 2014-04-16 at 16:13 +0200, Roger Pau Monne wrote:
> >> Add a simple vif-bridge script, that takes care of adding network
> >> backends (tap or xnb) to a pre-configured bridge.
> > 
> > Compared with the Linux one it lacks the handling of the vifname
> > property and the attempt to provide a default if no bridge was
> > specified. This is probably acceptable I suppose.
> 
> I would like to explicitly avoid providing a default bridge if no bridge
> was specified, I think this should probably be done in the global xl
> configuration file.

Is that what NetBSD does? I know Linux provides one, so FreeBSD should
either be the same as NetBSD or Linux (so if NetBSD provides a default
so should FreeBSD).

> > OOI why the x prefixes everywhere?
> 
> Because they were there on the NetBSD version, but I will remove them in
> the next version of the series.

Feel free to leave them if you would rather not diverge (with the aim of
eventually merging). Up to you though.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 14/23] hotplug: add FreeBSD vif-bridge

[Roger Pau Monné]

On 02/06/14 15:52, Ian Campbell wrote:
> On Mon, 2014-06-02 at 13:56 +0200, Roger Pau Monné wrote:
>> On 28/04/14 16:39, Ian Campbell wrote:
>>> On Wed, 2014-04-16 at 16:13 +0200, Roger Pau Monne wrote:
>>>> Add a simple vif-bridge script, that takes care of adding network
>>>> backends (tap or xnb) to a pre-configured bridge.
>>>
>>> Compared with the Linux one it lacks the handling of the vifname
>>> property and the attempt to provide a default if no bridge was
>>> specified. This is probably acceptable I suppose.
>>
>> I would like to explicitly avoid providing a default bridge if no bridge
>> was specified, I think this should probably be done in the global xl
>> configuration file.
> 
> Is that what NetBSD does? I know Linux provides one, so FreeBSD should
> either be the same as NetBSD or Linux (so if NetBSD provides a default
> so should FreeBSD).

NetBSD doesn't seem to provide a default bridge, here is what NetBSD
does in vif-bridge:

xbridge=$(xenstore-read "$xpath/bridge")
[...]
brconfig $xbridge add $iface

>>> OOI why the x prefixes everywhere?
>>
>> Because they were there on the NetBSD version, but I will remove them in
>> the next version of the series.
> 
> Feel free to leave them if you would rather not diverge (with the aim of
> eventually merging). Up to you though.

I've removed the "x" prefixes, since I think they are not helpful. Later
on we can remove them from the NetBSD script if there's interest in
merging them.

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 14/23] hotplug: add FreeBSD vif-bridge

[Ian Campbell]

On Mon, 2014-06-02 at 16:46 +0200, Roger Pau Monné wrote:
> On 02/06/14 15:52, Ian Campbell wrote:
> > On Mon, 2014-06-02 at 13:56 +0200, Roger Pau Monné wrote:
> >> On 28/04/14 16:39, Ian Campbell wrote:
> >>> On Wed, 2014-04-16 at 16:13 +0200, Roger Pau Monne wrote:
> >>>> Add a simple vif-bridge script, that takes care of adding network
> >>>> backends (tap or xnb) to a pre-configured bridge.
> >>>
> >>> Compared with the Linux one it lacks the handling of the vifname
> >>> property and the attempt to provide a default if no bridge was
> >>> specified. This is probably acceptable I suppose.
> >>
> >> I would like to explicitly avoid providing a default bridge if no bridge
> >> was specified, I think this should probably be done in the global xl
> >> configuration file.
> > 
> > Is that what NetBSD does? I know Linux provides one, so FreeBSD should
> > either be the same as NetBSD or Linux (so if NetBSD provides a default
> > so should FreeBSD).
> 
> NetBSD doesn't seem to provide a default bridge, here is what NetBSD
> does in vif-bridge:
> 
> xbridge=$(xenstore-read "$xpath/bridge")
> [...]
> brconfig $xbridge add $iface

OK, then I'm fine with FreeBSD not having a default either.

> 
> >>> OOI why the x prefixes everywhere?
> >>
> >> Because they were there on the NetBSD version, but I will remove them in
> >> the next version of the series.
> > 
> > Feel free to leave them if you would rather not diverge (with the aim of
> > eventually merging). Up to you though.
> 
> I've removed the "x" prefixes, since I think they are not helpful. Later
> on we can remove them from the NetBSD script if there's interest in
> merging them.

Sure.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[PATCH RFC 15/23] libxl: add support for OS-specific names to backend interfaces

[Roger Pau Monne]

libxl__device_nic_devname used to hardcode backend network interfaces
as "vif<domid>.<handle>", remove this limitation and allow libxl to
deal with OS-specific interface names.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c        |    4 ++--
 tools/libxl/libxl_osdeps.h |    2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 30b0b06..2249265 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3171,9 +3171,9 @@ const char *libxl__device_nic_devname(libxl__gc *gc,
 {
     switch (type) {
     case LIBXL_NIC_TYPE_VIF:
-        return GCSPRINTF("vif%u.%d", domid, devid);
+        return GCSPRINTF(NETBACK_NIC_NAME, domid, devid);
     case LIBXL_NIC_TYPE_VIF_IOEMU:
-        return GCSPRINTF("vif%u.%d" TAP_DEVICE_SUFFIX, domid, devid);
+        return GCSPRINTF(NETBACK_NIC_NAME TAP_DEVICE_SUFFIX, domid, devid);
     default:
         abort();
     }
diff --git a/tools/libxl/libxl_osdeps.h b/tools/libxl/libxl_osdeps.h
index f91bc79..aea83ee 100644
--- a/tools/libxl/libxl_osdeps.h
+++ b/tools/libxl/libxl_osdeps.h
@@ -26,12 +26,14 @@
 #if defined(__NetBSD__)
 #define SYSFS_PCI_DEV          "/sys/bus/pci/devices"
 #define SYSFS_PCIBACK_DRIVER   "/kern/xen/pci"
+#define NETBACK_NIC_NAME       "xvif%ui%d"
 #include <util.h>
 #elif defined(__OpenBSD__)
 #include <util.h>
 #elif defined(__linux__)
 #define SYSFS_PCI_DEV          "/sys/bus/pci/devices"
 #define SYSFS_PCIBACK_DRIVER   "/sys/bus/pci/drivers/pciback"
+#define NETBACK_NIC_NAME       "vif%u.%d"
 #include <pty.h>
 #elif defined(__sun__)
 #include <stropts.h>
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 15/23] libxl: add support for OS-specific names to backend interfaces

[Ian Jackson]

Roger Pau Monne writes ("[PATCH RFC 15/23] libxl: add support for OS-specific names to backend interfaces"):
> libxl__device_nic_devname used to hardcode backend network interfaces
> as "vif<domid>.<handle>", remove this limitation and allow libxl to
> deal with OS-specific interface names.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

[PATCH RFC 16/23] libxl: add FreeBSD OS support

[Roger Pau Monne]

Create a new libxl_freebsd.c file that contains OS-specific bits used
by libxl.

This currently defines which backend to use to handle disks, and
which hotplug scripts to execute.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/Makefile        |    4 +
 tools/libxl/libxl_freebsd.c |  133 +++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_osdeps.h  |    5 ++
 3 files changed, 142 insertions(+), 0 deletions(-)
 create mode 100644 tools/libxl/libxl_freebsd.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 755b666..ee8cf00 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -52,10 +52,14 @@ else
 ifeq ($(CONFIG_Linux),y)
 LIBXL_OBJS-y += libxl_linux.o
 else
+ifeq ($(CONFIG_FreeBSD),y)
+LIBXL_OBJS-y += libxl_freebsd.o
+else
 $(error Your Operating System is not supported by libxenlight, \
 please check libxl_linux.c and libxl_netbsd.c to see how to get it ported)
 endif
 endif
+endif
 
 ifeq ($(FLEX),)
 %.c %.h:: %.l
diff --git a/tools/libxl/libxl_freebsd.c b/tools/libxl/libxl_freebsd.c
new file mode 100644
index 0000000..c131e7a
--- /dev/null
+++ b/tools/libxl/libxl_freebsd.c
@@ -0,0 +1,133 @@
+/*
+ * Copyright (C) 2014
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+ 
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+int libxl__try_phy_backend(mode_t st_mode)
+{
+    if (S_ISREG(st_mode) || S_ISBLK(st_mode) || S_ISCHR(st_mode))
+        return 1;
+
+    return 0;
+}
+
+char *libxl__devid_to_localdev(libxl__gc *gc, int devid)
+{
+    /* TODO */
+    return NULL;
+}
+
+/* Hotplug scripts caller functions */
+static int libxl__hotplug_env_nic(libxl__gc *gc, libxl__device *dev, char ***env,
+                                  int num_exec)
+{
+    int nr = 0;
+    const int arraysize = 5;
+    libxl_nic_type type;
+
+    assert(dev->backend_kind == LIBXL__DEVICE_KIND_VIF);
+
+    /*
+     * On the first pass the PV interface is added to the bridge,
+     * on the second pass the tap interface will also be added.
+     */
+    type = num_exec == 0 ? LIBXL_NIC_TYPE_VIF : LIBXL_NIC_TYPE_VIF_IOEMU;
+
+    GCNEW_ARRAY(*env, arraysize);
+    (*env)[nr++] = "iface_dev";
+    (*env)[nr++] = (char *) libxl__device_nic_devname(gc, dev->domid,
+                                                      dev->devid, type);
+    (*env)[nr++] = "emulated";
+    (*env)[nr++] = type == LIBXL_NIC_TYPE_VIF_IOEMU ? "1" : "0";
+    (*env)[nr++] = NULL;
+    assert(nr == arraysize);
+
+    return 0;
+}
+
+static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev, char ***args,
+                              libxl__device_action action)
+{
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script;
+    int nr = 0, rc = 0, arraysize = 4;
+
+    assert(dev->backend_kind == LIBXL__DEVICE_KIND_VIF);
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            GCSPRINTF("%s/%s", be_path, "script"));
+    if (!script) {
+        LOGEV(ERROR, errno, "unable to read script from %s", be_path);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    GCNEW_ARRAY(*args, arraysize);
+    (*args)[nr++] = script;
+    (*args)[nr++] = be_path;
+    (*args)[nr++] = GCSPRINTF("%s", action == LIBXL__DEVICE_ACTION_ADD ?
+                                    "add" : "remove");
+    (*args)[nr++] = NULL;
+    assert(nr == arraysize);
+
+out:
+    return rc;
+}
+
+int libxl__get_hotplug_script_info(libxl__gc *gc, libxl__device *dev,
+                                   char ***args, char ***env,
+                                   libxl__device_action action,
+                                   int num_exec)
+{
+    libxl_nic_type nictype;
+    int rc;
+
+    if (dev->backend_kind != LIBXL__DEVICE_KIND_VIF || num_exec == 2)
+        return 0;
+
+    rc = libxl__nic_type(gc, dev, &nictype);
+    if (rc) {
+        LOG(ERROR, "error when fetching nic type");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    /*
+     * For PV domains only one pass is needed (because there's no emulated
+     * interface). For HVM domains two passes are needed in order to add
+     * both the PV and the tap interfaces to the bridge.
+     */
+    if (nictype == LIBXL_NIC_TYPE_VIF && num_exec != 0) {
+        rc = 0;
+        goto out;
+    }
+
+    rc = libxl__hotplug_env_nic(gc, dev, env, num_exec);
+    if (rc)
+        goto out;
+
+    rc = libxl__hotplug_nic(gc, dev, args, action);
+    if (!rc) rc = 1;
+
+out:
+    return rc;
+}
+
+libxl_device_model_version libxl__default_device_model(libxl__gc *gc)
+{
+    return LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
+}
diff --git a/tools/libxl/libxl_osdeps.h b/tools/libxl/libxl_osdeps.h
index aea83ee..08eaf0c 100644
--- a/tools/libxl/libxl_osdeps.h
+++ b/tools/libxl/libxl_osdeps.h
@@ -37,6 +37,11 @@
 #include <pty.h>
 #elif defined(__sun__)
 #include <stropts.h>
+#elif defined(__FreeBSD__)
+#define SYSFS_PCI_DEV          "/dev/null"
+#define SYSFS_PCIBACK_DRIVER   "/dev/null"
+#define NETBACK_NIC_NAME       "xnb%u.%d"
+#include <libutil.h>
 #endif
 
 #ifndef SYSFS_PCIBACK_DRIVER
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 16/23] libxl: add FreeBSD OS support

[Ian Jackson]

Roger Pau Monne writes ("[PATCH RFC 16/23] libxl: add FreeBSD OS support"):
> Create a new libxl_freebsd.c file that contains OS-specific bits used
> by libxl.
> 
> This currently defines which backend to use to handle disks, and
> which hotplug scripts to execute.

Are there no disk scripts on FreeBSD ?

Ian.

Re: [PATCH RFC 16/23] libxl: add FreeBSD OS support

[Roger Pau Monné]

On 17/04/14 19:10, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH RFC 16/23] libxl: add FreeBSD OS support"):
>> Create a new libxl_freebsd.c file that contains OS-specific bits used
>> by libxl.
>>
>> This currently defines which backend to use to handle disks, and
>> which hotplug scripts to execute.
> 
> Are there no disk scripts on FreeBSD ?

Not yet, I will look into adding hotplug script support for disks, but
it's something that I was planning to do after getting initial tools
support.

Roger.

[PATCH RFC 17/23] libxl: add support for FreeBSD uuid implementation

[Roger Pau Monne]

Add the FreeBSD specific uuid implementation. Since uuid_t is not
defined as an array, but as a struct on FreeBSD, use a union with a
array in order to be able to return the uuid as a bytearray.

Also, added a libxl internal compile time assert macro, that is used
to assert that the size of uuid_t is the same as the union used in
libxl.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |    4 +++
 tools/libxl/libxl_uuid.c     |   51 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_uuid.h     |   12 ++++++++++
 3 files changed, 67 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c2b73c4..9f8ab49 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3085,6 +3085,10 @@ void libxl__numa_candidate_put_nodemap(libxl__gc *gc,
  */
 #define CTYPE(isfoo,c) (isfoo((unsigned char)(c)))
 
+/*
+ * Compile time assertion
+ */
+#define BUILD_BUG_ON(p) ((void)sizeof(char[1 - 2 * !!(p)]))
 
 #endif
 
diff --git a/tools/libxl/libxl_uuid.c b/tools/libxl/libxl_uuid.c
index ecc29c7..4b35e88 100644
--- a/tools/libxl/libxl_uuid.c
+++ b/tools/libxl/libxl_uuid.c
@@ -102,6 +102,57 @@ uint8_t *libxl_uuid_bytearray(libxl_uuid *uuid)
     return uuid->uuid;
 }
 
+#elif defined(__FreeBSD__)
+
+int libxl_uuid_is_nil(libxl_uuid *uuid)
+{
+
+    return uuid_is_nil(&uuid->uuid, NULL);
+}
+
+void libxl_uuid_generate(libxl_uuid *uuid)
+{
+    uint32_t status;
+
+    BUILD_BUG_ON(sizeof(libxl_uuid) != sizeof(uuid_t));
+    uuid_create(&uuid->uuid, &status);
+    assert(status == uuid_s_ok);
+}
+
+int libxl_uuid_from_string(libxl_uuid *uuid, const char *in)
+{
+    uint32_t status;
+
+    uuid_from_string(in, &uuid->uuid, &status);
+    if (status != uuid_s_ok)
+        return -1;
+    return 0;
+}
+
+void libxl_uuid_copy(libxl_uuid *dst, const libxl_uuid *src)
+{
+
+    memcpy(&dst->uuid, &src->uuid, sizeof(dst->uuid));
+}
+
+void libxl_uuid_clear(libxl_uuid *uuid)
+{
+
+    memset(&uuid->uuid, 0, sizeof(uuid->uuid));
+}
+
+int libxl_uuid_compare(libxl_uuid *uuid1, libxl_uuid *uuid2)
+{
+
+    return uuid_compare(&uuid1->uuid, &uuid2->uuid, NULL);
+}
+
+uint8_t *libxl_uuid_bytearray(libxl_uuid *uuid)
+{
+
+    return uuid->uuid_raw;
+}
+
 #else
 
 #error "Please update libxl_uuid.c for your OS"
diff --git a/tools/libxl/libxl_uuid.h b/tools/libxl/libxl_uuid.h
index 93c65a7..3604180 100644
--- a/tools/libxl/libxl_uuid.h
+++ b/tools/libxl/libxl_uuid.h
@@ -47,6 +47,18 @@ typedef struct {
     uint8_t uuid[16];
 } libxl_uuid;
 
+#elif defined(__FreeBSD__)
+
+#include <uuid.h>
+#include <stdint.h>
+
+typedef union {
+    uuid_t uuid;
+    uint8_t uuid_raw[16];
+} libxl_uuid;
+
+#define LIBXL_UUID_BYTES(arg) LIBXL__UUID_BYTES(arg.uuid_raw)
+
 #else
 
 #error "Please update libxl_uuid.h for your OS"
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 17/23] libxl: add support for FreeBSD uuid implementation

[Ian Jackson]

Roger Pau Monne writes ("[PATCH RFC 17/23] libxl: add support for FreeBSD uuid implementation"):
> Add the FreeBSD specific uuid implementation. Since uuid_t is not
> defined as an array, but as a struct on FreeBSD, use a union with a
> array in order to be able to return the uuid as a bytearray.

I don't have a FreeBSD machine here to hand, but if it's a struct full
of >1-byte objects, aren't there endian problems with this approach ?

Ian.

Re: [PATCH RFC 17/23] libxl: add support for FreeBSD uuid implementation

[Roger Pau Monné]

On 17/04/14 19:11, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH RFC 17/23] libxl: add support for FreeBSD uuid implementation"):
>> Add the FreeBSD specific uuid implementation. Since uuid_t is not
>> defined as an array, but as a struct on FreeBSD, use a union with a
>> array in order to be able to return the uuid as a bytearray.
> 
> I don't have a FreeBSD machine here to hand, but if it's a struct full
> of >1-byte objects, aren't there endian problems with this approach ?

I'm frankly not familiar at all with uuid or how it's supposed to work,
but from what I saw, the NetBSD and FreeBSD implementations of uuid are
very similar (most of FreeBSD code seems to be picked from NetBSD).

I'm not sure what endian problems can come out of it, NetBSD uses the
same approach. The only difference is that NetBSD directly defines the
uuid field as an array, but on FreeBSD I've preferred to use a union of
the native type with an array (so native functions get called by passing
the right type, which is uuid_t), while libxl can still make use of the
byte array.

Roger.

[PATCH RFC 18/23] libxl: only include utmp.h if it's present

[Roger Pau Monne]

Add a configure check for utmp.h presence, and gate the usage of
utmp.h in libxl to the result of the test.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/config.h.in              |    3 +++
 tools/configure.ac             |    2 +-
 tools/libxl/libxl_bootloader.c |    2 ++
 3 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/tools/config.h.in b/tools/config.h.in
index 709a51d..842e766 100644
--- a/tools/config.h.in
+++ b/tools/config.h.in
@@ -60,6 +60,9 @@
 /* Define to 1 if you have the <asm/unaligned.h> header file. */
 #undef HAVE_ASM_UNALIGNED_H
 
+/* Define to 1 if you have the <utmp.h> header file. */
+#undef HAVE_UTMP_H
+
 /* Define curses header to use */
 #undef INCLUDE_CURSES_H
 
diff --git a/tools/configure.ac b/tools/configure.ac
index cf30254..2a4a729 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -247,7 +247,7 @@ AC_CHECK_LIB([fdt], [fdt_create], [], [AC_MSG_ERROR([Could not find libfdt])])
 esac
 
 # Checks for header files.
-AC_CHECK_HEADERS([yajl/yajl_version.h sys/eventfd.h endian.h sys/endian.h asm/unaligned.h])
+AC_CHECK_HEADERS([yajl/yajl_version.h sys/eventfd.h endian.h sys/endian.h asm/unaligned.h utmp.h])
 
 AC_OUTPUT()
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 3287bf7..c3ec782 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -15,7 +15,9 @@
 #include "libxl_osdeps.h" /* must come before any other headers */
 
 #include <termios.h>
+#ifdef HAVE_UTMP_H
 #include <utmp.h>
+#endif
 
 #ifdef INCLUDE_LIBUTIL_H
 #include INCLUDE_LIBUTIL_H
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 18/23] libxl: only include utmp.h if it's present

[Ian Jackson]

Roger Pau Monne writes ("[PATCH RFC 18/23] libxl: only include utmp.h if it's present"):
> Add a configure check for utmp.h presence, and gate the usage of
> utmp.h in libxl to the result of the test.

I don't object to this, but: on FreeBSD, which header defines
login_tty then ?

Ian.

Re: [PATCH RFC 18/23] libxl: only include utmp.h if it's present

[Roger Pau Monné]

On 17/04/14 19:13, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH RFC 18/23] libxl: only include utmp.h if it's present"):
>> Add a configure check for utmp.h presence, and gate the usage of
>> utmp.h in libxl to the result of the test.
> 
> I don't object to this, but: on FreeBSD, which header defines
> login_tty then ?

It's in libutil.h:

http://www.freebsd.org/cgi/man.cgi?query=login_tty&apropos=0&sektion=0&manpath=FreeBSD+10.0-RELEASE&arch=default&format=html

which is already included by libxl_osdeps.h.

Roger.

Re: [PATCH RFC 18/23] libxl: only include utmp.h if it's present

[Ian Jackson]

Roger Pau Monné writes ("Re: [PATCH RFC 18/23] libxl: only include utmp.h if it's present"):
> On 17/04/14 19:13, Ian Jackson wrote:
> > I don't object to this, but: on FreeBSD, which header defines
> > login_tty then ?
> 
> It's in libutil.h:
> 
> http://www.freebsd.org/cgi/man.cgi?query=login_tty&apropos=0&sektion=0&manpath=FreeBSD+10.0-RELEASE&arch=default&format=html
> 
> which is already included by libxl_osdeps.h.

OK, good.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

[PATCH RFC 19/23] hvmloader: remove size_t typedef and include stddef.h

[Roger Pau Monne]

The open coded typedef of size_t was clashing with the typedef in
FreeBSD headers. Remove the typedef and include the proper header
where size_t is defined (stddef.h).

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/firmware/hvmloader/util.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index 9ccb905..46d32b9 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -3,6 +3,7 @@
 
 #include <stdarg.h>
 #include <stdint.h>
+#include <stddef.h>
 #include <xen/xen.h>
 #include <xen/hvm/hvm_info_table.h>
 
@@ -174,7 +175,6 @@ int printf(const char *fmt, ...) __attribute__ ((format (printf, 1, 2)));
 int vprintf(const char *fmt, va_list ap);
 
 /* Buffer output */
-typedef unsigned long size_t;
 int snprintf(char *buf, size_t size, const char *fmt, ...) __attribute__ ((format (printf, 3, 4)));
 
 /* Populate specified memory hole with RAM. */
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 19/23] hvmloader: remove size_t typedef and include stddef.h

[Ian Campbell]

On Wed, 2014-04-16 at 16:13 +0200, Roger Pau Monne wrote:
> The open coded typedef of size_t was clashing with the typedef in
> FreeBSD headers. Remove the typedef and include the proper header
> where size_t is defined (stddef.h).
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> ---
>  tools/firmware/hvmloader/util.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
> index 9ccb905..46d32b9 100644
> --- a/tools/firmware/hvmloader/util.h
> +++ b/tools/firmware/hvmloader/util.h

> @@ -3,6 +3,7 @@
>  
>  #include <stdarg.h>
>  #include <stdint.h>
> +#include <stddef.h>

This isn't really userspace code, it's essentially a little kernel. So
I'm not sure what the impact of including stddef.h is. I suppose it is
probably OK.

Xen itself seems to use "typedef __SIZE_TYPE__ size_t" without
ill-affects, on *BSD too I suppose.

>  #include <xen/xen.h>
>  #include <xen/hvm/hvm_info_table.h>
>  
> @@ -174,7 +175,6 @@ int printf(const char *fmt, ...) __attribute__ ((format (printf, 1, 2)));
>  int vprintf(const char *fmt, va_list ap);
>  
>  /* Buffer output */
> -typedef unsigned long size_t;
>  int snprintf(char *buf, size_t size, const char *fmt, ...) __attribute__ ((format (printf, 3, 4)));
>  
>  /* Populate specified memory hole with RAM. */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 19/23] hvmloader: remove size_t typedef and include stddef.h

[Roger Pau Monné]

On 28/04/14 16:43, Ian Campbell wrote:
> On Wed, 2014-04-16 at 16:13 +0200, Roger Pau Monne wrote:
>> The open coded typedef of size_t was clashing with the typedef in
>> FreeBSD headers. Remove the typedef and include the proper header
>> where size_t is defined (stddef.h).
>>
>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
>> Cc: Ian Campbell <ian.campbell@citrix.com>
>> ---
>>  tools/firmware/hvmloader/util.h |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
>> index 9ccb905..46d32b9 100644
>> --- a/tools/firmware/hvmloader/util.h
>> +++ b/tools/firmware/hvmloader/util.h
> 
>> @@ -3,6 +3,7 @@
>>  
>>  #include <stdarg.h>
>>  #include <stdint.h>
>> +#include <stddef.h>
> 
> This isn't really userspace code, it's essentially a little kernel. So
> I'm not sure what the impact of including stddef.h is. I suppose it is
> probably OK.
> 
> Xen itself seems to use "typedef __SIZE_TYPE__ size_t" without
> ill-affects, on *BSD too I suppose.

I don't have a strong opinion regarding what to do, but hvmloader/util.h
already includes stdarg.h and stdint.h, so adding also stddef.h seemed
the best way. I plan to resend this as-is unless someone clearly objects.

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 19/23] hvmloader: remove size_t typedef and include stddef.h

[Ian Campbell]

On Mon, 2014-06-02 at 14:13 +0200, Roger Pau Monné wrote:
> On 28/04/14 16:43, Ian Campbell wrote:
> > On Wed, 2014-04-16 at 16:13 +0200, Roger Pau Monne wrote:
> >> The open coded typedef of size_t was clashing with the typedef in
> >> FreeBSD headers. Remove the typedef and include the proper header
> >> where size_t is defined (stddef.h).
> >>
> >> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> >> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
> >> Cc: Ian Campbell <ian.campbell@citrix.com>
> >> ---
> >>  tools/firmware/hvmloader/util.h |    2 +-
> >>  1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
> >> index 9ccb905..46d32b9 100644
> >> --- a/tools/firmware/hvmloader/util.h
> >> +++ b/tools/firmware/hvmloader/util.h
> > 
> >> @@ -3,6 +3,7 @@
> >>  
> >>  #include <stdarg.h>
> >>  #include <stdint.h>
> >> +#include <stddef.h>
> > 
> > This isn't really userspace code, it's essentially a little kernel. So
> > I'm not sure what the impact of including stddef.h is. I suppose it is
> > probably OK.
> > 
> > Xen itself seems to use "typedef __SIZE_TYPE__ size_t" without
> > ill-affects, on *BSD too I suppose.
> 
> I don't have a strong opinion regarding what to do, but hvmloader/util.h
> already includes stdarg.h and stdint.h, so adding also stddef.h seemed
> the best way. I plan to resend this as-is unless someone clearly objects.

Hrm, that probably ought to be fixed, but I suppose that is for another
time. So for now: Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[PATCH RFC 20/23] xenstat: add a dummy FreeBSD implementation

[Roger Pau Monne]

Add an empty FreeBSD implementation so xenstat can compile on FreeBSD.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstat/libxenstat/Makefile              |    1 +
 tools/xenstat/libxenstat/src/xenstat_freebsd.c |   47 ++++++++++++++++++++++++
 2 files changed, 48 insertions(+), 0 deletions(-)
 create mode 100644 tools/xenstat/libxenstat/src/xenstat_freebsd.c

diff --git a/tools/xenstat/libxenstat/Makefile b/tools/xenstat/libxenstat/Makefile
index 21aad89..15dc22d 100644
--- a/tools/xenstat/libxenstat/Makefile
+++ b/tools/xenstat/libxenstat/Makefile
@@ -32,6 +32,7 @@ OBJECTS-y=src/xenstat.o
 OBJECTS-$(CONFIG_Linux) += src/xenstat_linux.o
 OBJECTS-$(CONFIG_SunOS) += src/xenstat_solaris.o
 OBJECTS-$(CONFIG_NetBSD) += src/xenstat_netbsd.o
+OBJECTS-$(CONFIG_FreeBSD) += src/xenstat_freebsd.o
 SONAME_FLAGS=-Wl,$(SONAME_LDFLAG) -Wl,libxenstat.so.$(MAJOR)
 
 WARN_FLAGS=-Wall -Werror
diff --git a/tools/xenstat/libxenstat/src/xenstat_freebsd.c b/tools/xenstat/libxenstat/src/xenstat_freebsd.c
new file mode 100644
index 0000000..0c488df
--- /dev/null
+++ b/tools/xenstat/libxenstat/src/xenstat_freebsd.c
@@ -0,0 +1,47 @@
+/* libxenstat: statistics-collection library for Xen
+ * Copyright (C) International Business Machines Corp., 2005
+ * Authors: Josh Triplett <josht@us.ibm.com>
+ *          Judy Fischbach <jfisch@us.ibm.com>
+ *          David Hendricks <dhendrix@us.ibm.com>
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ */
+
+/*
+ * Copyright 2007 Sun Microsystems, Inc.  All rights reserved.
+ * Use is subject to license terms.
+ */
+
+#include "xenstat_priv.h"
+
+/* Collect information about networks */
+int xenstat_collect_networks(xenstat_node * node)
+{
+
+	return 1;
+}
+
+/* Free network information in handle */
+void xenstat_uninit_networks(xenstat_handle * handle)
+{
+}
+
+/* Collect information about VBDs */
+int xenstat_collect_vbds(xenstat_node * node)
+{
+
+	return 1;
+}
+
+/* Free VBD information in handle */
+void xenstat_uninit_vbds(xenstat_handle * handle)
+{
+}
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 20/23] xenstat: add a dummy FreeBSD implementation

[Ian Jackson]

Roger Pau Monne writes ("[PATCH RFC 20/23] xenstat: add a dummy FreeBSD implementation"):
> Add an empty FreeBSD implementation so xenstat can compile on FreeBSD.

Not an area I'm very familiar with.

Have you tried running xentop with this patch and seen what it does ?

Thanks,
Ian.

Re: [PATCH RFC 20/23] xenstat: add a dummy FreeBSD implementation

[Roger Pau Monné]

On 17/04/14 19:15, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH RFC 20/23] xenstat: add a dummy FreeBSD implementation"):
>> Add an empty FreeBSD implementation so xenstat can compile on FreeBSD.
> 
> Not an area I'm very familiar with.
> 
> Have you tried running xentop with this patch and seen what it does ?

Yes, disk and network stats are not reported, here is a sample output:

      NAME  STATE   CPU(sec) CPU(%)     MEM(k) MEM(%)  MAXMEM(k) MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS   VBD_OO   VBD_RD   VBD_WR  VBD_RSECT  VBD_WSECT SSID
  Domain-0 -----r        697    0.0    1048568   16.7   no limit       n/a     2    0        0     0    0        0        0        0          0          0    0
      test --b---          7    0.0     524288    8.3     525312       8.4     1    0        0     0    0        0        0        0          0          0    0

Roger.

Re: [PATCH RFC 20/23] xenstat: add a dummy FreeBSD implementation

[Ian Jackson]

Roger Pau Monné writes ("Re: [PATCH RFC 20/23] xenstat: add a dummy FreeBSD implementation"):
> On 17/04/14 19:15, Ian Jackson wrote:
> > Have you tried running xentop with this patch and seen what it does ?
> 
> Yes, disk and network stats are not reported, here is a sample output:

Great.  Thanks.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

Re: [PATCH RFC 20/23] xenstat: add a dummy FreeBSD implementation

[Ian Campbell]

On Wed, 2014-04-16 at 16:13 +0200, Roger Pau Monne wrote:
> Add an empty FreeBSD implementation so xenstat can compile on FreeBSD.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> ---
>  tools/xenstat/libxenstat/Makefile              |    1 +
>  tools/xenstat/libxenstat/src/xenstat_freebsd.c |   47 ++++++++++++++++++++++++
>  2 files changed, 48 insertions(+), 0 deletions(-)
>  create mode 100644 tools/xenstat/libxenstat/src/xenstat_freebsd.c
> 
> diff --git a/tools/xenstat/libxenstat/Makefile b/tools/xenstat/libxenstat/Makefile
> index 21aad89..15dc22d 100644
> --- a/tools/xenstat/libxenstat/Makefile
> +++ b/tools/xenstat/libxenstat/Makefile
> @@ -32,6 +32,7 @@ OBJECTS-y=src/xenstat.o
>  OBJECTS-$(CONFIG_Linux) += src/xenstat_linux.o
>  OBJECTS-$(CONFIG_SunOS) += src/xenstat_solaris.o
>  OBJECTS-$(CONFIG_NetBSD) += src/xenstat_netbsd.o
> +OBJECTS-$(CONFIG_FreeBSD) += src/xenstat_freebsd.o

How about doing this as a xenstat_unimplemented.c?

On the other hand I suppose this will go away before too long and be
replaced with a proper one.

>  SONAME_FLAGS=-Wl,$(SONAME_LDFLAG) -Wl,libxenstat.so.$(MAJOR)
>  
>  WARN_FLAGS=-Wall -Werror
> diff --git a/tools/xenstat/libxenstat/src/xenstat_freebsd.c b/tools/xenstat/libxenstat/src/xenstat_freebsd.c
> new file mode 100644
> index 0000000..0c488df
> --- /dev/null
> +++ b/tools/xenstat/libxenstat/src/xenstat_freebsd.c
> @@ -0,0 +1,47 @@
> +/* libxenstat: statistics-collection library for Xen
> + * Copyright (C) International Business Machines Corp., 2005
> + * Authors: Josh Triplett <josht@us.ibm.com>
> + *          Judy Fischbach <jfisch@us.ibm.com>
> + *          David Hendricks <dhendrix@us.ibm.com>

Truely?

> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + */
> +
> +/*
> + * Copyright 2007 Sun Microsystems, Inc.  All rights reserved.
> + * Use is subject to license terms.

Really?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[PATCH RFC 21/23] gdbsx: remove cast from ioctl

[Roger Pau Monne]

The ulong type is not defined on FreeBSD, and the cast seems
pointless, so just remove it.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/debugger/gdbsx/xg/xg_main.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/debugger/gdbsx/xg/xg_main.c b/tools/debugger/gdbsx/xg/xg_main.c
index 0fc3f82..c95e4ed 100644
--- a/tools/debugger/gdbsx/xg/xg_main.c
+++ b/tools/debugger/gdbsx/xg/xg_main.c
@@ -180,7 +180,7 @@ _domctl_hcall(uint32_t cmd,            /* which domctl hypercall */
     hypercall.op = __HYPERVISOR_domctl;
     hypercall.arg[0] = (unsigned long)&domctl;
 
-    rc = ioctl(_dom0_fd, IOCTL_PRIVCMD_HYPERCALL, (ulong)&hypercall);
+    rc = ioctl(_dom0_fd, IOCTL_PRIVCMD_HYPERCALL, &hypercall);
     if (domctlarg && sz)
         munlock(domctlarg, sz);
     return rc;
@@ -220,7 +220,7 @@ _check_hyp(int guest_bitness)
     hypercall.arg[0] = (unsigned long)XENVER_capabilities;
     hypercall.arg[1] = (unsigned long)&xen_caps;
 
-    rc = ioctl(_dom0_fd, IOCTL_PRIVCMD_HYPERCALL, (ulong)&hypercall);
+    rc = ioctl(_dom0_fd, IOCTL_PRIVCMD_HYPERCALL, &hypercall);
     munlock(&xen_caps, sizeof(xen_caps));
     XGTRC("XENCAPS:%s\n", xen_caps);
 
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 21/23] gdbsx: remove cast from ioctl

[Ian Jackson]

Roger Pau Monne writes ("[PATCH RFC 21/23] gdbsx: remove cast from ioctl"):
> The ulong type is not defined on FreeBSD, and the cast seems
> pointless, so just remove it.

I think this is very likely to be correct.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Re: [PATCH RFC 21/23] gdbsx: remove cast from ioctl

[Ian Campbell]

On Thu, 2014-04-17 at 18:17 +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH RFC 21/23] gdbsx: remove cast from ioctl"):
> > The ulong type is not defined on FreeBSD, and the cast seems
> > pointless, so just remove it.
> 
> I think this is very likely to be correct.

The danger is systems where sizeof(ulong) != sizeof(struct somehing *).
I think we can sleep easy and not worry about that.

> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Agreed. Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ian.

Re: [PATCH RFC 21/23] gdbsx: remove cast from ioctl

[Mukesh Rathor]

On Mon, 28 Apr 2014 15:46:26 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Thu, 2014-04-17 at 18:17 +0100, Ian Jackson wrote:
> > Roger Pau Monne writes ("[PATCH RFC 21/23] gdbsx: remove cast from
> > ioctl"):
> > > The ulong type is not defined on FreeBSD, and the cast seems
> > > pointless, so just remove it.
> > 
> > I think this is very likely to be correct.
> 
> The danger is systems where sizeof(ulong) != sizeof(struct somehing
> *). I think we can sleep easy and not worry about that.
> 
> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Agreed. Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Ian.

Acked-by: Mukesh Rathor <mukesh.rathor@oracle.com>

[PATCH RFC 22/23] build: export CC value to SeaBIOS

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/firmware/Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index cb13212..dcb56e5 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -36,7 +36,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
 	false ; \
 	fi
 endif
-	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
+	$(MAKE) CC=$(CC) PYTHON=$(PYTHON) subdirs-$@
 
 
 .PHONY: install
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 22/23] build: export CC value to SeaBIOS

[Ian Campbell]

On Wed, 2014-04-16 at 16:13 +0200, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> ---
>  tools/firmware/Makefile |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
> index cb13212..dcb56e5 100644
> --- a/tools/firmware/Makefile
> +++ b/tools/firmware/Makefile
> @@ -36,7 +36,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
>  	false ; \
>  	fi
>  endif
> -	$(MAKE) PYTHON=$(PYTHON) subdirs-$@
> +	$(MAKE) CC=$(CC) PYTHON=$(PYTHON) subdirs-$@

I'm a bit surprised this isn't either already exported or that this
construct isn't more prevalent, but whatever:
Acked-by: Ian Campbell <ian.campbell@citrix.com>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[PATCH RFC 23/23] build: export linker emulation parameter to SeaBIOS

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/firmware/Makefile |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index dcb56e5..092f1bc 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -17,6 +17,10 @@ SUBDIRS-$(CONFIG_ROMBIOS) += vgabios
 SUBDIRS-$(CONFIG_ROMBIOS) += etherboot
 SUBDIRS-y += hvmloader
 
+LD32BIT-$(CONFIG_FreeBSD) := -melf_i386_fbsd
+LD32BIT-$(CONFIG_NetBSD) := -melf_i386
+LD32BIT-$(CONFIG_Linux) := -melf_i386
+
 ovmf-dir:
 	GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(OVMF_UPSTREAM_URL) $(OVMF_UPSTREAM_REVISION) ovmf-dir
 	cp ovmf-makefile ovmf-dir/Makefile;
@@ -36,7 +40,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
 	false ; \
 	fi
 endif
-	$(MAKE) CC=$(CC) PYTHON=$(PYTHON) subdirs-$@
+	$(MAKE) LD32BIT_FLAG=$(LD32BIT-y) CC=$(CC) PYTHON=$(PYTHON) subdirs-$@
 
 
 .PHONY: install
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 23/23] build: export linker emulation parameter to SeaBIOS

[Ian Campbell]

On Wed, 2014-04-16 at 16:13 +0200, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> ---
>  tools/firmware/Makefile |    6 +++++-
>  1 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
> index dcb56e5..092f1bc 100644
> --- a/tools/firmware/Makefile
> +++ b/tools/firmware/Makefile
> @@ -17,6 +17,10 @@ SUBDIRS-$(CONFIG_ROMBIOS) += vgabios
>  SUBDIRS-$(CONFIG_ROMBIOS) += etherboot
>  SUBDIRS-y += hvmloader
>  
> +LD32BIT-$(CONFIG_FreeBSD) := -melf_i386_fbsd
> +LD32BIT-$(CONFIG_NetBSD) := -melf_i386
> +LD32BIT-$(CONFIG_Linux) := -melf_i386

Can we do this as

LD32BIT-$(CONFIG_FreeBSD) := LD32BIT_FLAG=-m....

Then pass $(LD32BIT-y) to $(MAKE).

IOW avoid needlessly overriding it.

Given that most OSes seem to support melf as well as their native
emulation I don't suppose you want to take this up with the FreeBSD
folks?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC 00/23] tools: add support for FreeBSD

[Roger Pau Monné]

On 16/04/14 16:13, Roger Pau Monne wrote:
> The following series enables building (and using) the Xen toolstack on 
> a FreeBSD PVH Dom0.
> 
> The FreeBSD sources used to test this series can be found at:
> 
> git://xenbits.xen.org/people/royger/freebsd.git branch pvh_dom0_v3
> http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvh_dom0_v3
> 
> I've successfully tested PV and HVM domains, but right now only 
> qemu-xen (aka qemu-upstream) is supported on FreeBSD (in order to 
> avoid the build system from trying to compile qemu-trad pass the 
> following option to configure: --disable-qemu-traditional). I'm not 
> sure if there's any gain from also having qemu-trad, so I would 
> suggest to automatically disable it on FreeBSD (like we do for ARM).
> 
> Some patches for Qemu and SeaBIOS are needed, which are still pending 
> approval from their respective upstreams:
> 
> http://marc.info/?l=xen-devel&m=139763253311569
> http://marc.info/?l=xen-devel&m=139755086616838&w=2

Forgot to mention the series can also be found on my git repo:

git://xenbits.xen.org/people/royger/xen.git branch freebsd_tools_rfc

http://xenbits.xen.org/gitweb/?p=people/royger/xen.git;a=shortlog;h=refs/heads/freebsd_tools_rfc

Roger.

Re: [PATCH RFC 00/23] tools: add support for FreeBSD

[Ian Campbell]

On Wed, 2014-04-16 at 16:13 +0200, Roger Pau Monne wrote:
> The following series enables building (and using) the Xen toolstack on 
> a FreeBSD PVH Dom0.

Applied:
 01/23] build: set FreeBSD specific build variables
 05/23] libxc: remove usage of "daylight" variable
 06/23] libxc: remove include of malloc.h
 07/23] libelf: add defines for bswap_* functions for FreeBSD
 11/23] xenstore: add some missing headers
 15/23] libxl: add support for OS-specific names to backend interfaces
 20/23] xenstat: add a dummy FreeBSD implementation
 21/23] gdbsx: remove cast from ioctl
 22/23] build: export CC value to SeaBIOS

Didn't apply when I tried:
 18/23] libxl: only include utmp.h if it's present

Re: [PATCH RFC 00/23] tools: add support for FreeBSD

[Ian Campbell]

On Wed, 2014-04-16 at 16:13 +0200, Roger Pau Monne wrote:
> The following series enables building (and using) the Xen toolstack on 
> a FreeBSD PVH Dom0.

Applied:
 01/23] build: set FreeBSD specific build variables
 05/23] libxc: remove usage of "daylight" variable
 06/23] libxc: remove include of malloc.h
 07/23] libelf: add defines for bswap_* functions for FreeBSD
 11/23] xenstore: add some missing headers
 15/23] libxl: add support for OS-specific names to backend interfaces
 20/23] xenstat: add a dummy FreeBSD implementation
 21/23] gdbsx: remove cast from ioctl
 22/23] build: export CC value to SeaBIOS

Didn't apply when I tried:
 18/23] libxl: only include utmp.h if it's present