All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [Xen-users] XEN/arm XENFB support
       [not found] <WC20131216081609.85000C@perkbv.com>
@ 2013-12-16  8:45 ` Lars Kurth
  2013-12-16  9:59   ` Ian Campbell
  0 siblings, 1 reply; 8+ messages in thread
From: Lars Kurth @ 2013-12-16  8:45 UTC (permalink / raw)
  To: peter; +Cc: xen-users, xen-devel


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

Adding xen-devel
Lars


On Mon, Dec 16, 2013 at 8:16 AM, peter <peter@perkbv.com> wrote:

> Goodmorning,
>
> I'm currently playing with XEN/arm on my Allwinner A20 (cubieboard2)
> I would like to get the XENFB driver working on domU.
> But currently in xen/arm there's no support for VFB, atleast qemu is not
> supported.
> But this video http://www.youtube.com/watch?v=po1IeElg8tg and this one
> http://www.youtube.com/watch?v=Km6gBnIqaWo is showing a working
> framebuffer.
> So there are people which got a framebuffer working on domU.
> But still i couldn't find anything on the internet how to do this.
> Is there anyone with experience with VFB on xen/arm ?
>
> Greetings,
>
> Peter van der Perk
>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users
>

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

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

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Xen-users] XEN/arm XENFB support
  2013-12-16  8:45 ` [Xen-users] XEN/arm XENFB support Lars Kurth
@ 2013-12-16  9:59   ` Ian Campbell
  2013-12-17  7:20     ` peter
  0 siblings, 1 reply; 8+ messages in thread
From: Ian Campbell @ 2013-12-16  9:59 UTC (permalink / raw)
  To: peter; +Cc: Lars Kurth, xen-users, xen-devel

On Mon, 2013-12-16 at 08:45 +0000, Lars Kurth wrote:

> On Mon, Dec 16, 2013 at 8:16 AM, peter <peter@perkbv.com> wrote:
>         I'm currently playing with XEN/arm on my Allwinner A20 (cubieboard2)
>         I would like to get the XENFB driver working on domU.
>         But currently in xen/arm there's no support for VFB, atleast qemu is not
>         supported.
>         But this video http://www.youtube.com/watch?v=po1IeElg8tg and this one
>         http://www.youtube.com/watch?v=Km6gBnIqaWo is showing a working framebuffer.
>         So there are people which got a framebuffer working on domU.
>         But still i couldn't find anything on the internet how to do this.
>         Is there anyone with experience with VFB on xen/arm ?

I'm not sure what the first link used but the second was using a form of
hybrid GPU passthrough/paravirtualisation for which the code has not
been reeleased and AFAIK has nothing to do with VFB.

I've not tried VFB on ARM yet (busy with other things) but I suspect
that if you were to build upstream qemu on ARM with Xen support enabled
then it would just work. I would recommend giving that a go -- please
let us know how you get on.

Below is a patch which I wrote ages ago that I have just rebased onto
current xen staging *without retesting*. It is supposed to DTWT and
enable the qemu build for ARM (as well as providing a mechanism to start
the correct dom0 qemu, which you don't need for vfb).

As I say I haven't tested, or even built, and in particular I never
tried PVFB with it even what I wrote it, so YMMV.

Ian.


commit 7b5d54c9a5d09c4138bec905c9accea34173ba77
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Wed May 15 16:34:55 2013 +0100

    tools: build and launch correct qemu for architecture
    
    xl now provides a launch-dom0-qemu command which avoids the need to have the
    initscripts be aware of the specific qermu binary name, which differs by
    architecture and which also may have been specified by the user via the
    --with-system-qemu=PATH option to configure.
    
    Perhaps this should be a separate binary hidden in libexec?
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/config/arm32.mk b/config/arm32.mk
index aa79d22..f3599a3 100644
--- a/config/arm32.mk
+++ b/config/arm32.mk
@@ -3,6 +3,8 @@ CONFIG_ARM_32 := y
 CONFIG_ARM_$(XEN_OS) := y
 
 CONFIG_XEN_INSTALL_SUFFIX :=
+CONFIG_QEMU_ARCH := arm
+CONFIG_QEMU_TARGET := arm-softmmu
 
 # -march= -mcpu=
 
diff --git a/config/arm64.mk b/config/arm64.mk
index 15b57a4..4ff15e0 100644
--- a/config/arm64.mk
+++ b/config/arm64.mk
@@ -3,6 +3,8 @@ CONFIG_ARM_64 := y
 CONFIG_ARM_$(XEN_OS) := y
 
 CONFIG_XEN_INSTALL_SUFFIX :=
+CONFIG_QEMU_ARCH := aarch64
+CONFIG_QEMU_TARGET := arm-softmmu
 
 CFLAGS += #-marm -march= -mcpu= etc
 
diff --git a/config/x86_32.mk b/config/x86_32.mk
index 7f76b25..da3111d 100644
--- a/config/x86_32.mk
+++ b/config/x86_32.mk
@@ -2,6 +2,9 @@ CONFIG_X86 := y
 CONFIG_X86_32 := y
 CONFIG_X86_$(XEN_OS) := y
 
+CONFIG_QEMU_ARCH := i386
+CONFIG_QEMU_TARGET := i386-softmmu
+
 CONFIG_HVM := y
 CONFIG_MIGRATE := y
 CONFIG_XCUTILS := y
diff --git a/config/x86_64.mk b/config/x86_64.mk
index 11104bd..f59e36d 100644
--- a/config/x86_64.mk
+++ b/config/x86_64.mk
@@ -2,6 +2,9 @@ CONFIG_X86 := y
 CONFIG_X86_64 := y
 CONFIG_X86_$(XEN_OS) := y
 
+CONFIG_QEMU_ARCH := x86_64
+CONFIG_QEMU_ARCH := i386-softmmu
+
 CONFIG_COMPAT := y
 CONFIG_HVM := y
 CONFIG_MIGRATE := y
diff --git a/tools/Makefile b/tools/Makefile
index 00c69ee..250b931 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -107,7 +107,7 @@ distclean: subdirs-distclean
 		config.cache autom4te.cache
 
 ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
-IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \
+IOEMU_CONFIGURE_CROSS ?= --cpu=$(CONFIG_QEMU_ARCH) \
 			 --cross-prefix=$(CROSS_COMPILE) \
 			 --interp-prefix=$(CROSS_SYS_ROOT)
 endif
@@ -186,8 +186,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
 		source=.; \
 	fi; \
 	cd qemu-xen-dir; \
-	$$source/configure --enable-xen --target-list=i386-softmmu \
-		$(QEMU_XEN_ENABLE_DEBUG) \
+	$$source/configure --enable-xen --target-list=$(CONFIG_QEMU_TARGET) \
 		--prefix=$(PREFIX) \
 		--source-path=$$source \
 		--extra-cflags="-I$(XEN_ROOT)/tools/include \
diff --git a/tools/hotplug/Linux/init.d/xencommons b/tools/hotplug/Linux/init.d/xencommons
index 4ebd636..f568085 100644
--- a/tools/hotplug/Linux/init.d/xencommons
+++ b/tools/hotplug/Linux/init.d/xencommons
@@ -116,11 +116,7 @@ do_start () {
 	echo Starting xenconsoled...
 	test -z "$XENCONSOLED_TRACE" || XENCONSOLED_ARGS=" --log=$XENCONSOLED_TRACE"
 	${SBINDIR}/xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS
-	echo Starting QEMU as disk backend for dom0
-	test -z "$QEMU_XEN" && QEMU_XEN="${LIBEXEC}/qemu-system-i386"
-	$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize \
-		-monitor /dev/null -serial /dev/null -parallel /dev/null \
-		-pidfile $QEMU_PIDFILE
+	xl launch-dom0-qemu $QEMU_XEN
 }
 do_stop () {
         echo Stopping xenconsoled
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index d8495bb..d8b6a5c 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -27,6 +27,7 @@ CFLAGS_LIBXL += $(CFLAGS_libxenguest)
 CFLAGS_LIBXL += $(CFLAGS_libxenstore)
 CFLAGS_LIBXL += $(CFLAGS_libblktapctl) 
 CFLAGS_LIBXL += -Wshadow
+CFLAGS_LIBXL += -DCONFIG_QEMU_ARCH=\"$(CONFIG_QEMU_ARCH)\"
 
 LIBXL_LIBS-$(CONFIG_ARM) += -lfdt
 
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 12d6c31..0287a35 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -605,6 +605,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
                     xentoollog_logger *lg);
 int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 
+/* exec's device model for dom0 and does not return. */
+void libxl_launch_dom0_qemu(libxl_ctx *ctx, const char *qemu_path, const char *pidfile);
+
 /* domain related functions */
 
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index f6f7bbd..f0b13a9 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -38,7 +38,7 @@ static const char *qemu_xen_path(libxl__gc *gc)
 #ifdef QEMU_XEN_PATH
     return QEMU_XEN_PATH;
 #else
-    return libxl__abs_path(gc, "qemu-system-i386", libxl__libexec_path());
+    return libxl__abs_path(gc, "qemu-system-" CONFIG_QEMU_ARCH, libxl__libexec_path());
 #endif
 }
 
@@ -1560,6 +1560,37 @@ out:
     return ret;
 }
 
+void libxl_launch_dom0_qemu(libxl_ctx *ctx, const char *qemu_path, const char *pidfile)
+{
+    GC_INIT(ctx);
+
+    flexarray_t *dm_args = flexarray_make(gc, 16, 1);
+
+    if (qemu_path == NULL)
+        qemu_path = qemu_xen_path(gc);
+
+    flexarray_vappend(dm_args,
+                      "-xen-domid", "0",
+                      "-xen-attach",
+                      "-name", "dom0",
+                      "-nographic",
+                      "-M" "xenpv",
+                      "-daemonize",
+                      "-monitor", "/dev/null",
+                      "-serial", "/dev/null",
+                      "-parallel", "/dev/null",
+                      NULL);
+    if (pidfile)
+        flexarray_append_pair(dm_args, "-pidfile", libxl__strdup(gc, pidfile));
+
+    libxl__exec(gc, -1, -1, -1,
+                qemu_path, (char **)flexarray_contents(dm_args), NULL);
+
+    /* Shouldn't return */
+    LOG(CRITICAL, "Failed to exec dom0 device model");
+    GC_FREE;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index c876a33..1d7602c 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -106,6 +106,7 @@ int main_setenforce(int argc, char **argv);
 int main_loadpolicy(int argc, char **argv);
 int main_remus(int argc, char **argv);
 int main_devd(int argc, char **argv);
+int main_launch_dom0_qemu(int argc, char **argv);
 
 void help(const char *command);
 
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index bd26bcc..108dfac 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -7313,6 +7313,31 @@ out:
     return ret;
 }
 
+int main_launch_dom0_qemu(int argc, char **argv)
+{
+    int opt;
+    const char *qemu = NULL;
+    const char *pidfile = NULL;
+
+    SWITCH_FOREACH_OPT(opt, "p:", NULL, "launch-dom-qemu", 0) {
+    case 'p':
+        pidfile = optarg;
+        break;
+        /* No options */
+    }
+    if (optind < argc)
+        qemu = argv[optind];
+
+    fprintf(stderr, "argc %d\n", argc);
+    fprintf(stderr, "qemu = %s", qemu ? : "<default>");
+
+    fprintf(stdout, "Starting QEMU as disk backend for dom0");
+
+    libxl_launch_dom0_qemu(ctx, qemu, pidfile);
+
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
index ebe0220..ab4d56c 100644
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -494,6 +494,12 @@ struct cmd_spec cmd_table[] = {
       "[options]",
       "-F                      Run in the foreground",
     },
+    { "launch-dom0-qemu",
+      &main_launch_dom0_qemu, 0, 1,
+      "Start qemu process to service dom0 disk backends",
+      "[options] [QEMU_PATH]",
+      "-p PIDFILE              Write a PIDFILE\n",
+    },
 };
 
 int cmdtable_len = sizeof(cmd_table)/sizeof(struct cmd_spec);

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [Xen-users] XEN/arm XENFB support
  2013-12-16  9:59   ` Ian Campbell
@ 2013-12-17  7:20     ` peter
  2013-12-17  9:53       ` Ian Campbell
  2013-12-17 15:55       ` Stefano Stabellini
  0 siblings, 2 replies; 8+ messages in thread
From: peter @ 2013-12-17  7:20 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Lars Kurth, xen-users, xen-devel

Thank you for the info/patch Ian.
With some modifications to Qemu, I managed to cross compile
qemu-system-arm with XEN support.
Based on version: 1c514a7734b7f98625a0d18d5e8ee7581f26e50c (Merge remote
branch 'perard/cpu-hotplug-port-v2' into xen-staging-master-7).
And got my Qemu backend working.

I can see that INPUT_XEN_KBDDEV_FRONTEND is working
(d9) 6input: Xen Virtual Keyboard as /devices/virtual/input/input0
(d9) 6input: Xen Virtual Pointer as /devices/virtual/input/input1

And that XEN bus is prompting for VFB
(d9) 6xenbus_probe_frontend: Device with no driver: device/vfb/0

But it seems that the xen-fbfront only supports PV and not PVH. (Linux
kernel 3.12-RC5)
Because the init code is returning on:

	if (!xen_pv_domain())
		return -ENODEV;

When I comment this code out.
I do get these errors:

[ 1698.899496] Failed to unmap pfn:5c081 rc:-2

(XEN) dom10 IPA 0x0000000000000000
(XEN) P2M @ 021b8300 mfn:0x4dc18
(XEN) 1ST[0x0] = 0x000000004da276ff
(XEN) 2ND[0x0] = 0x000000006b6856ff
(XEN) 3RD[0x0] = 0x0000000000000000
[ 1698.933034] Failed to map pfn to mfn rc:0:-22 pfn:5c349 mfn:0

(XEN) dom10 IPA 0x000000002777c000
(XEN) P2M @ 021b8300 mfn:0x4dc18
(XEN) 1ST[0x0] = 0x000000004da276ff
(XEN) 2ND[0x13b] = 0x0000000000000000
[ 1698.951353] Failed to map pfn to mfn rc:0:-22 pfn:5c348 mfn:b6b2777c

Yes lots of them, and my VFB is not working tough.

So I've searched on the internet if someone got VFB on PVH working.
But I couldn't find anything about, so is there someone who got VFB
working on PVH (x86) ?


-----Original Message-----
From: Ian Campbell <Ian.Campbell@citrix.com>
To: peter <peter@perkbv.com>
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Lars Kurth
<lars.kurth.xen@gmail.com>
Date: Mon, 16 Dec 2013 09:59:09 +0000
Subject: Re: [Xen-devel] [Xen-users] XEN/arm XENFB support

> On Mon, 2013-12-16 at 08:45 +0000, Lars Kurth wrote:
> 
> > On Mon, Dec 16, 2013 at 8:16 AM, peter <peter@perkbv.com> wrote:
> >         I'm currently playing with XEN/arm on my Allwinner A20
> (cubieboard2)
> >         I would like to get the XENFB driver working on domU.
> >         But currently in xen/arm there's no support for VFB, atleast
> qemu is not
> >         supported.
> >         But this video http://www.youtube.com/watch?v=po1IeElg8tg and
> this one
> >         http://www.youtube.com/watch?v=Km6gBnIqaWo is showing a
> working framebuffer.
> >         So there are people which got a framebuffer working on domU.
> >         But still i couldn't find anything on the internet how to do
> this.
> >         Is there anyone with experience with VFB on xen/arm ?
> 
> I'm not sure what the first link used but the second was using a form
> of
> hybrid GPU passthrough/paravirtualisation for which the code has not
> been reeleased and AFAIK has nothing to do with VFB.
> 
> I've not tried VFB on ARM yet (busy with other things) but I suspect
> that if you were to build upstream qemu on ARM with Xen support enabled
> then it would just work. I would recommend giving that a go -- please
> let us know how you get on.
> 
> Below is a patch which I wrote ages ago that I have just rebased onto
> current xen staging *without retesting*. It is supposed to DTWT and
> enable the qemu build for ARM (as well as providing a mechanism to
> start
> the correct dom0 qemu, which you don't need for vfb).
> 
> As I say I haven't tested, or even built, and in particular I never
> tried PVFB with it even what I wrote it, so YMMV.
> 
> Ian.
> 
> 
> commit 7b5d54c9a5d09c4138bec905c9accea34173ba77
> Author: Ian Campbell <ian.campbell@citrix.com>
> Date:   Wed May 15 16:34:55 2013 +0100
> 
>     tools: build and launch correct qemu for architecture
>     
>     xl now provides a launch-dom0-qemu command which avoids the need to
> have the
>     initscripts be aware of the specific qermu binary name, which
> differs by
>     architecture and which also may have been specified by the user via
> the
>     --with-system-qemu=PATH option to configure.
>     
>     Perhaps this should be a separate binary hidden in libexec?
>     
>     Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff --git a/config/arm32.mk b/config/arm32.mk
> index aa79d22..f3599a3 100644
> --- a/config/arm32.mk
> +++ b/config/arm32.mk
> @@ -3,6 +3,8 @@ CONFIG_ARM_32 := y
>  CONFIG_ARM_$(XEN_OS) := y
>  
>  CONFIG_XEN_INSTALL_SUFFIX :=
> +CONFIG_QEMU_ARCH := arm
> +CONFIG_QEMU_TARGET := arm-softmmu
>  
>  # -march= -mcpu=
>  
> diff --git a/config/arm64.mk b/config/arm64.mk
> index 15b57a4..4ff15e0 100644
> --- a/config/arm64.mk
> +++ b/config/arm64.mk
> @@ -3,6 +3,8 @@ CONFIG_ARM_64 := y
>  CONFIG_ARM_$(XEN_OS) := y
>  
>  CONFIG_XEN_INSTALL_SUFFIX :=
> +CONFIG_QEMU_ARCH := aarch64
> +CONFIG_QEMU_TARGET := arm-softmmu
>  
>  CFLAGS += #-marm -march= -mcpu= etc
>  
> diff --git a/config/x86_32.mk b/config/x86_32.mk
> index 7f76b25..da3111d 100644
> --- a/config/x86_32.mk
> +++ b/config/x86_32.mk
> @@ -2,6 +2,9 @@ CONFIG_X86 := y
>  CONFIG_X86_32 := y
>  CONFIG_X86_$(XEN_OS) := y
>  
> +CONFIG_QEMU_ARCH := i386
> +CONFIG_QEMU_TARGET := i386-softmmu
> +
>  CONFIG_HVM := y
>  CONFIG_MIGRATE := y
>  CONFIG_XCUTILS := y
> diff --git a/config/x86_64.mk b/config/x86_64.mk
> index 11104bd..f59e36d 100644
> --- a/config/x86_64.mk
> +++ b/config/x86_64.mk
> @@ -2,6 +2,9 @@ CONFIG_X86 := y
>  CONFIG_X86_64 := y
>  CONFIG_X86_$(XEN_OS) := y
>  
> +CONFIG_QEMU_ARCH := x86_64
> +CONFIG_QEMU_ARCH := i386-softmmu
> +
>  CONFIG_COMPAT := y
>  CONFIG_HVM := y
>  CONFIG_MIGRATE := y
> diff --git a/tools/Makefile b/tools/Makefile
> index 00c69ee..250b931 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -107,7 +107,7 @@ distclean: subdirs-distclean
>  		config.cache autom4te.cache
>  
>  ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
> -IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \
> +IOEMU_CONFIGURE_CROSS ?= --cpu=$(CONFIG_QEMU_ARCH) \
>  			 --cross-prefix=$(CROSS_COMPILE) \
>  			 --interp-prefix=$(CROSS_SYS_ROOT)
>  endif
> @@ -186,8 +186,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
>  		source=.; \
>  	fi; \
>  	cd qemu-xen-dir; \
> -	$$source/configure --enable-xen --target-list=i386-softmmu \
> -		$(QEMU_XEN_ENABLE_DEBUG) \
> +	$$source/configure --enable-xen --target-list=$(CONFIG_QEMU_TARGET) \
>  		--prefix=$(PREFIX) \
>  		--source-path=$$source \
>  		--extra-cflags="-I$(XEN_ROOT)/tools/include \
> diff --git a/tools/hotplug/Linux/init.d/xencommons
> b/tools/hotplug/Linux/init.d/xencommons
> index 4ebd636..f568085 100644
> --- a/tools/hotplug/Linux/init.d/xencommons
> +++ b/tools/hotplug/Linux/init.d/xencommons
> @@ -116,11 +116,7 @@ do_start () {
>  	echo Starting xenconsoled...
>  	test -z "$XENCONSOLED_TRACE" || XENCONSOLED_ARGS="
> --log=$XENCONSOLED_TRACE"
>  	${SBINDIR}/xenconsoled --pid-file=$XENCONSOLED_PIDFILE
> $XENCONSOLED_ARGS
> -	echo Starting QEMU as disk backend for dom0
> -	test -z "$QEMU_XEN" && QEMU_XEN="${LIBEXEC}/qemu-system-i386"
> -	$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv
> -daemonize \
> -		-monitor /dev/null -serial /dev/null -parallel /dev/null \
> -		-pidfile $QEMU_PIDFILE
> +	xl launch-dom0-qemu $QEMU_XEN
>  }
>  do_stop () {
>          echo Stopping xenconsoled
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index d8495bb..d8b6a5c 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -27,6 +27,7 @@ CFLAGS_LIBXL += $(CFLAGS_libxenguest)
>  CFLAGS_LIBXL += $(CFLAGS_libxenstore)
>  CFLAGS_LIBXL += $(CFLAGS_libblktapctl) 
>  CFLAGS_LIBXL += -Wshadow
> +CFLAGS_LIBXL += -DCONFIG_QEMU_ARCH=\"$(CONFIG_QEMU_ARCH)\"
>  
>  LIBXL_LIBS-$(CONFIG_ARM) += -lfdt
>  
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 12d6c31..0287a35 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -605,6 +605,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>                      xentoollog_logger *lg);
>  int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
>  
> +/* exec's device model for dom0 and does not return. */
> +void libxl_launch_dom0_qemu(libxl_ctx *ctx, const char *qemu_path,
> const char *pidfile);
> +
>  /* domain related functions */
>  
>  int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config
> *d_config,
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index f6f7bbd..f0b13a9 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -38,7 +38,7 @@ static const char *qemu_xen_path(libxl__gc *gc)
>  #ifdef QEMU_XEN_PATH
>      return QEMU_XEN_PATH;
>  #else
> -    return libxl__abs_path(gc, "qemu-system-i386",
> libxl__libexec_path());
> +    return libxl__abs_path(gc, "qemu-system-" CONFIG_QEMU_ARCH,
> libxl__libexec_path());
>  #endif
>  }
>  
> @@ -1560,6 +1560,37 @@ out:
>      return ret;
>  }
>  
> +void libxl_launch_dom0_qemu(libxl_ctx *ctx, const char *qemu_path,
> const char *pidfile)
> +{
> +    GC_INIT(ctx);
> +
> +    flexarray_t *dm_args = flexarray_make(gc, 16, 1);
> +
> +    if (qemu_path == NULL)
> +        qemu_path = qemu_xen_path(gc);
> +
> +    flexarray_vappend(dm_args,
> +                      "-xen-domid", "0",
> +                      "-xen-attach",
> +                      "-name", "dom0",
> +                      "-nographic",
> +                      "-M" "xenpv",
> +                      "-daemonize",
> +                      "-monitor", "/dev/null",
> +                      "-serial", "/dev/null",
> +                      "-parallel", "/dev/null",
> +                      NULL);
> +    if (pidfile)
> +        flexarray_append_pair(dm_args, "-pidfile", libxl__strdup(gc,
> pidfile));
> +
> +    libxl__exec(gc, -1, -1, -1,
> +                qemu_path, (char **)flexarray_contents(dm_args),
> NULL);
> +
> +    /* Shouldn't return */
> +    LOG(CRITICAL, "Failed to exec dom0 device model");
> +    GC_FREE;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
> index c876a33..1d7602c 100644
> --- a/tools/libxl/xl.h
> +++ b/tools/libxl/xl.h
> @@ -106,6 +106,7 @@ int main_setenforce(int argc, char **argv);
>  int main_loadpolicy(int argc, char **argv);
>  int main_remus(int argc, char **argv);
>  int main_devd(int argc, char **argv);
> +int main_launch_dom0_qemu(int argc, char **argv);
>  
>  void help(const char *command);
>  
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index bd26bcc..108dfac 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -7313,6 +7313,31 @@ out:
>      return ret;
>  }
>  
> +int main_launch_dom0_qemu(int argc, char **argv)
> +{
> +    int opt;
> +    const char *qemu = NULL;
> +    const char *pidfile = NULL;
> +
> +    SWITCH_FOREACH_OPT(opt, "p:", NULL, "launch-dom-qemu", 0) {
> +    case 'p':
> +        pidfile = optarg;
> +        break;
> +        /* No options */
> +    }
> +    if (optind < argc)
> +        qemu = argv[optind];
> +
> +    fprintf(stderr, "argc %d\n", argc);
> +    fprintf(stderr, "qemu = %s", qemu ? : "<default>");
> +
> +    fprintf(stdout, "Starting QEMU as disk backend for dom0");
> +
> +    libxl_launch_dom0_qemu(ctx, qemu, pidfile);
> +
> +    return 0;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
> index ebe0220..ab4d56c 100644
> --- a/tools/libxl/xl_cmdtable.c
> +++ b/tools/libxl/xl_cmdtable.c
> @@ -494,6 +494,12 @@ struct cmd_spec cmd_table[] = {
>        "[options]",
>        "-F                      Run in the foreground",
>      },
> +    { "launch-dom0-qemu",
> +      &main_launch_dom0_qemu, 0, 1,
> +      "Start qemu process to service dom0 disk backends",
> +      "[options] [QEMU_PATH]",
> +      "-p PIDFILE              Write a PIDFILE\n",
> +    },
>  };
>  
>  int cmdtable_len = sizeof(cmd_table)/sizeof(struct cmd_spec);

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Xen-users] XEN/arm XENFB support
  2013-12-17  7:20     ` peter
@ 2013-12-17  9:53       ` Ian Campbell
  2013-12-17 15:55       ` Stefano Stabellini
  1 sibling, 0 replies; 8+ messages in thread
From: Ian Campbell @ 2013-12-17  9:53 UTC (permalink / raw)
  To: peter; +Cc: xen-devel

On Tue, 2013-12-17 at 08:20 +0100, peter wrote:

Please can you avoid top posting on the -devel list.

I've put -users and Lars to bcc since I think we are now well into
-devel territory.

> Thank you for the info/patch Ian.
> With some modifications to Qemu, I managed to cross compile
> qemu-system-arm with XEN support.
> Based on version: 1c514a7734b7f98625a0d18d5e8ee7581f26e50c (Merge remote
> branch 'perard/cpu-hotplug-port-v2' into xen-staging-master-7).
> And got my Qemu backend working.
> 
> I can see that INPUT_XEN_KBDDEV_FRONTEND is working
> (d9) 6input: Xen Virtual Keyboard as /devices/virtual/input/input0
> (d9) 6input: Xen Virtual Pointer as /devices/virtual/input/input1
> 
> And that XEN bus is prompting for VFB
> (d9) 6xenbus_probe_frontend: Device with no driver: device/vfb/0
> 
> But it seems that the xen-fbfront only supports PV and not PVH. (Linux
> kernel 3.12-RC5)
> Because the init code is returning on:
> 
> 	if (!xen_pv_domain())
> 		return -ENODEV;
> 
> When I comment this code out.
> I do get these errors:
> 
> [ 1698.899496] Failed to unmap pfn:5c081 rc:-2
> 
> (XEN) dom10 IPA 0x0000000000000000
> (XEN) P2M @ 021b8300 mfn:0x4dc18
> (XEN) 1ST[0x0] = 0x000000004da276ff
> (XEN) 2ND[0x0] = 0x000000006b6856ff
> (XEN) 3RD[0x0] = 0x0000000000000000
> [ 1698.933034] Failed to map pfn to mfn rc:0:-22 pfn:5c349 mfn:0
> 
> (XEN) dom10 IPA 0x000000002777c000
> (XEN) P2M @ 021b8300 mfn:0x4dc18
> (XEN) 1ST[0x0] = 0x000000004da276ff
> (XEN) 2ND[0x13b] = 0x0000000000000000
> [ 1698.951353] Failed to map pfn to mfn rc:0:-22 pfn:5c348 mfn:b6b2777c
> 
> Yes lots of them, and my VFB is not working tough.
> 
> So I've searched on the internet if someone got VFB on PVH working.
> But I couldn't find anything about, so is there someone who got VFB
> working on PVH (x86) ?

I've not heard of anyone, the focus of x86-PVH has been on getting the
basic functionality going.

In general PV drivers should just work but in some corner cases they
need adjustments for the "autotranslate" (i.e. hardware assisted paging)
case which is one of the key areas where both ARM, PVH-x86 and HVM-x86
differ from traditional PV-x86 guests.

So it might be that the vfb driver requires some such adjustment, or it
might be that the foreign mapping stuff is not working for you -- which
would be the same issue as you are having with domain building in the
other thread.

Given that I think we should try and get to the bottom of the foreign
mapping stuff first.

Eventually it might be worth investigating
http://xen.1045712.n5.nabble.com/PATCH-Add-grant-references-for-fbfront-kbdfront-td3332068.html since the fb driver didn't really ought to be using foreign mappings anyway -- it should use grant references. However those patches only cover the frontend case and the author was using something other than qemu as the backend, so there is at least some actual development work required here.

Ian.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Xen-users] XEN/arm XENFB support
  2013-12-17  7:20     ` peter
  2013-12-17  9:53       ` Ian Campbell
@ 2013-12-17 15:55       ` Stefano Stabellini
  2013-12-17 16:42         ` Stefano Stabellini
  1 sibling, 1 reply; 8+ messages in thread
From: Stefano Stabellini @ 2013-12-17 15:55 UTC (permalink / raw)
  To: peter; +Cc: Lars Kurth, xen-users, Ian Campbell, xen-devel

On Tue, 17 Dec 2013, peter wrote:
> Thank you for the info/patch Ian.
> With some modifications to Qemu, I managed to cross compile
> qemu-system-arm with XEN support.
> Based on version: 1c514a7734b7f98625a0d18d5e8ee7581f26e50c (Merge remote
> branch 'perard/cpu-hotplug-port-v2' into xen-staging-master-7).
> And got my Qemu backend working.

Nice! Could you please post your patch?


> I can see that INPUT_XEN_KBDDEV_FRONTEND is working
> (d9) 6input: Xen Virtual Keyboard as /devices/virtual/input/input0
> (d9) 6input: Xen Virtual Pointer as /devices/virtual/input/input1
> 
> And that XEN bus is prompting for VFB
> (d9) 6xenbus_probe_frontend: Device with no driver: device/vfb/0
> 
> But it seems that the xen-fbfront only supports PV and not PVH. (Linux
> kernel 3.12-RC5)
> Because the init code is returning on:
> 
> 	if (!xen_pv_domain())
> 		return -ENODEV;
> 
> When I comment this code out.

Yeah, it should be turned into:

if (!xen_domain())
    return -ENODEV;


> I do get these errors:
> 
> [ 1698.899496] Failed to unmap pfn:5c081 rc:-2

These ones should be unrelated and not fatal, and Julien is working to
fix the underlying issue.


> (XEN) dom10 IPA 0x0000000000000000
> (XEN) P2M @ 021b8300 mfn:0x4dc18
> (XEN) 1ST[0x0] = 0x000000004da276ff
> (XEN) 2ND[0x0] = 0x000000006b6856ff
> (XEN) 3RD[0x0] = 0x0000000000000000
> [ 1698.933034] Failed to map pfn to mfn rc:0:-22 pfn:5c349 mfn:0
> 
> (XEN) dom10 IPA 0x000000002777c000
> (XEN) P2M @ 021b8300 mfn:0x4dc18
> (XEN) 1ST[0x0] = 0x000000004da276ff
> (XEN) 2ND[0x13b] = 0x0000000000000000
> [ 1698.951353] Failed to map pfn to mfn rc:0:-22 pfn:5c348 mfn:b6b2777c
> 
> Yes lots of them, and my VFB is not working tough.

I suspect these are the actual symptoms of the problem.
Looking around the frontend and the backend I couldn't find the issue.
If you post your patch I might give it a try.


 
> So I've searched on the internet if someone got VFB on PVH working.
> But I couldn't find anything about, so is there someone who got VFB
> working on PVH (x86) ?
> 
> 
> -----Original Message-----
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: peter <peter@perkbv.com>
> Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
> "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Lars Kurth
> <lars.kurth.xen@gmail.com>
> Date: Mon, 16 Dec 2013 09:59:09 +0000
> Subject: Re: [Xen-devel] [Xen-users] XEN/arm XENFB support
> 
> > On Mon, 2013-12-16 at 08:45 +0000, Lars Kurth wrote:
> > 
> > > On Mon, Dec 16, 2013 at 8:16 AM, peter <peter@perkbv.com> wrote:
> > >         I'm currently playing with XEN/arm on my Allwinner A20
> > (cubieboard2)
> > >         I would like to get the XENFB driver working on domU.
> > >         But currently in xen/arm there's no support for VFB, atleast
> > qemu is not
> > >         supported.
> > >         But this video http://www.youtube.com/watch?v=po1IeElg8tg and
> > this one
> > >         http://www.youtube.com/watch?v=Km6gBnIqaWo is showing a
> > working framebuffer.
> > >         So there are people which got a framebuffer working on domU.
> > >         But still i couldn't find anything on the internet how to do
> > this.
> > >         Is there anyone with experience with VFB on xen/arm ?
> > 
> > I'm not sure what the first link used but the second was using a form
> > of
> > hybrid GPU passthrough/paravirtualisation for which the code has not
> > been reeleased and AFAIK has nothing to do with VFB.
> > 
> > I've not tried VFB on ARM yet (busy with other things) but I suspect
> > that if you were to build upstream qemu on ARM with Xen support enabled
> > then it would just work. I would recommend giving that a go -- please
> > let us know how you get on.
> > 
> > Below is a patch which I wrote ages ago that I have just rebased onto
> > current xen staging *without retesting*. It is supposed to DTWT and
> > enable the qemu build for ARM (as well as providing a mechanism to
> > start
> > the correct dom0 qemu, which you don't need for vfb).
> > 
> > As I say I haven't tested, or even built, and in particular I never
> > tried PVFB with it even what I wrote it, so YMMV.
> > 
> > Ian.
> > 
> > 
> > commit 7b5d54c9a5d09c4138bec905c9accea34173ba77
> > Author: Ian Campbell <ian.campbell@citrix.com>
> > Date:   Wed May 15 16:34:55 2013 +0100
> > 
> >     tools: build and launch correct qemu for architecture
> >     
> >     xl now provides a launch-dom0-qemu command which avoids the need to
> > have the
> >     initscripts be aware of the specific qermu binary name, which
> > differs by
> >     architecture and which also may have been specified by the user via
> > the
> >     --with-system-qemu=PATH option to configure.
> >     
> >     Perhaps this should be a separate binary hidden in libexec?
> >     
> >     Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > diff --git a/config/arm32.mk b/config/arm32.mk
> > index aa79d22..f3599a3 100644
> > --- a/config/arm32.mk
> > +++ b/config/arm32.mk
> > @@ -3,6 +3,8 @@ CONFIG_ARM_32 := y
> >  CONFIG_ARM_$(XEN_OS) := y
> >  
> >  CONFIG_XEN_INSTALL_SUFFIX :=
> > +CONFIG_QEMU_ARCH := arm
> > +CONFIG_QEMU_TARGET := arm-softmmu
> >  
> >  # -march= -mcpu=
> >  
> > diff --git a/config/arm64.mk b/config/arm64.mk
> > index 15b57a4..4ff15e0 100644
> > --- a/config/arm64.mk
> > +++ b/config/arm64.mk
> > @@ -3,6 +3,8 @@ CONFIG_ARM_64 := y
> >  CONFIG_ARM_$(XEN_OS) := y
> >  
> >  CONFIG_XEN_INSTALL_SUFFIX :=
> > +CONFIG_QEMU_ARCH := aarch64
> > +CONFIG_QEMU_TARGET := arm-softmmu
> >  
> >  CFLAGS += #-marm -march= -mcpu= etc
> >  
> > diff --git a/config/x86_32.mk b/config/x86_32.mk
> > index 7f76b25..da3111d 100644
> > --- a/config/x86_32.mk
> > +++ b/config/x86_32.mk
> > @@ -2,6 +2,9 @@ CONFIG_X86 := y
> >  CONFIG_X86_32 := y
> >  CONFIG_X86_$(XEN_OS) := y
> >  
> > +CONFIG_QEMU_ARCH := i386
> > +CONFIG_QEMU_TARGET := i386-softmmu
> > +
> >  CONFIG_HVM := y
> >  CONFIG_MIGRATE := y
> >  CONFIG_XCUTILS := y
> > diff --git a/config/x86_64.mk b/config/x86_64.mk
> > index 11104bd..f59e36d 100644
> > --- a/config/x86_64.mk
> > +++ b/config/x86_64.mk
> > @@ -2,6 +2,9 @@ CONFIG_X86 := y
> >  CONFIG_X86_64 := y
> >  CONFIG_X86_$(XEN_OS) := y
> >  
> > +CONFIG_QEMU_ARCH := x86_64
> > +CONFIG_QEMU_ARCH := i386-softmmu
> > +
> >  CONFIG_COMPAT := y
> >  CONFIG_HVM := y
> >  CONFIG_MIGRATE := y
> > diff --git a/tools/Makefile b/tools/Makefile
> > index 00c69ee..250b931 100644
> > --- a/tools/Makefile
> > +++ b/tools/Makefile
> > @@ -107,7 +107,7 @@ distclean: subdirs-distclean
> >  		config.cache autom4te.cache
> >  
> >  ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
> > -IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \
> > +IOEMU_CONFIGURE_CROSS ?= --cpu=$(CONFIG_QEMU_ARCH) \
> >  			 --cross-prefix=$(CROSS_COMPILE) \
> >  			 --interp-prefix=$(CROSS_SYS_ROOT)
> >  endif
> > @@ -186,8 +186,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
> >  		source=.; \
> >  	fi; \
> >  	cd qemu-xen-dir; \
> > -	$$source/configure --enable-xen --target-list=i386-softmmu \
> > -		$(QEMU_XEN_ENABLE_DEBUG) \
> > +	$$source/configure --enable-xen --target-list=$(CONFIG_QEMU_TARGET) \
> >  		--prefix=$(PREFIX) \
> >  		--source-path=$$source \
> >  		--extra-cflags="-I$(XEN_ROOT)/tools/include \
> > diff --git a/tools/hotplug/Linux/init.d/xencommons
> > b/tools/hotplug/Linux/init.d/xencommons
> > index 4ebd636..f568085 100644
> > --- a/tools/hotplug/Linux/init.d/xencommons
> > +++ b/tools/hotplug/Linux/init.d/xencommons
> > @@ -116,11 +116,7 @@ do_start () {
> >  	echo Starting xenconsoled...
> >  	test -z "$XENCONSOLED_TRACE" || XENCONSOLED_ARGS="
> > --log=$XENCONSOLED_TRACE"
> >  	${SBINDIR}/xenconsoled --pid-file=$XENCONSOLED_PIDFILE
> > $XENCONSOLED_ARGS
> > -	echo Starting QEMU as disk backend for dom0
> > -	test -z "$QEMU_XEN" && QEMU_XEN="${LIBEXEC}/qemu-system-i386"
> > -	$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv
> > -daemonize \
> > -		-monitor /dev/null -serial /dev/null -parallel /dev/null \
> > -		-pidfile $QEMU_PIDFILE
> > +	xl launch-dom0-qemu $QEMU_XEN
> >  }
> >  do_stop () {
> >          echo Stopping xenconsoled
> > diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> > index d8495bb..d8b6a5c 100644
> > --- a/tools/libxl/Makefile
> > +++ b/tools/libxl/Makefile
> > @@ -27,6 +27,7 @@ CFLAGS_LIBXL += $(CFLAGS_libxenguest)
> >  CFLAGS_LIBXL += $(CFLAGS_libxenstore)
> >  CFLAGS_LIBXL += $(CFLAGS_libblktapctl) 
> >  CFLAGS_LIBXL += -Wshadow
> > +CFLAGS_LIBXL += -DCONFIG_QEMU_ARCH=\"$(CONFIG_QEMU_ARCH)\"
> >  
> >  LIBXL_LIBS-$(CONFIG_ARM) += -lfdt
> >  
> > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> > index 12d6c31..0287a35 100644
> > --- a/tools/libxl/libxl.h
> > +++ b/tools/libxl/libxl.h
> > @@ -605,6 +605,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
> >                      xentoollog_logger *lg);
> >  int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
> >  
> > +/* exec's device model for dom0 and does not return. */
> > +void libxl_launch_dom0_qemu(libxl_ctx *ctx, const char *qemu_path,
> > const char *pidfile);
> > +
> >  /* domain related functions */
> >  
> >  int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config
> > *d_config,
> > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > index f6f7bbd..f0b13a9 100644
> > --- a/tools/libxl/libxl_dm.c
> > +++ b/tools/libxl/libxl_dm.c
> > @@ -38,7 +38,7 @@ static const char *qemu_xen_path(libxl__gc *gc)
> >  #ifdef QEMU_XEN_PATH
> >      return QEMU_XEN_PATH;
> >  #else
> > -    return libxl__abs_path(gc, "qemu-system-i386",
> > libxl__libexec_path());
> > +    return libxl__abs_path(gc, "qemu-system-" CONFIG_QEMU_ARCH,
> > libxl__libexec_path());
> >  #endif
> >  }
> >  
> > @@ -1560,6 +1560,37 @@ out:
> >      return ret;
> >  }
> >  
> > +void libxl_launch_dom0_qemu(libxl_ctx *ctx, const char *qemu_path,
> > const char *pidfile)
> > +{
> > +    GC_INIT(ctx);
> > +
> > +    flexarray_t *dm_args = flexarray_make(gc, 16, 1);
> > +
> > +    if (qemu_path == NULL)
> > +        qemu_path = qemu_xen_path(gc);
> > +
> > +    flexarray_vappend(dm_args,
> > +                      "-xen-domid", "0",
> > +                      "-xen-attach",
> > +                      "-name", "dom0",
> > +                      "-nographic",
> > +                      "-M" "xenpv",
> > +                      "-daemonize",
> > +                      "-monitor", "/dev/null",
> > +                      "-serial", "/dev/null",
> > +                      "-parallel", "/dev/null",
> > +                      NULL);
> > +    if (pidfile)
> > +        flexarray_append_pair(dm_args, "-pidfile", libxl__strdup(gc,
> > pidfile));
> > +
> > +    libxl__exec(gc, -1, -1, -1,
> > +                qemu_path, (char **)flexarray_contents(dm_args),
> > NULL);
> > +
> > +    /* Shouldn't return */
> > +    LOG(CRITICAL, "Failed to exec dom0 device model");
> > +    GC_FREE;
> > +}
> > +
> >  /*
> >   * Local variables:
> >   * mode: C
> > diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
> > index c876a33..1d7602c 100644
> > --- a/tools/libxl/xl.h
> > +++ b/tools/libxl/xl.h
> > @@ -106,6 +106,7 @@ int main_setenforce(int argc, char **argv);
> >  int main_loadpolicy(int argc, char **argv);
> >  int main_remus(int argc, char **argv);
> >  int main_devd(int argc, char **argv);
> > +int main_launch_dom0_qemu(int argc, char **argv);
> >  
> >  void help(const char *command);
> >  
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index bd26bcc..108dfac 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -7313,6 +7313,31 @@ out:
> >      return ret;
> >  }
> >  
> > +int main_launch_dom0_qemu(int argc, char **argv)
> > +{
> > +    int opt;
> > +    const char *qemu = NULL;
> > +    const char *pidfile = NULL;
> > +
> > +    SWITCH_FOREACH_OPT(opt, "p:", NULL, "launch-dom-qemu", 0) {
> > +    case 'p':
> > +        pidfile = optarg;
> > +        break;
> > +        /* No options */
> > +    }
> > +    if (optind < argc)
> > +        qemu = argv[optind];
> > +
> > +    fprintf(stderr, "argc %d\n", argc);
> > +    fprintf(stderr, "qemu = %s", qemu ? : "<default>");
> > +
> > +    fprintf(stdout, "Starting QEMU as disk backend for dom0");
> > +
> > +    libxl_launch_dom0_qemu(ctx, qemu, pidfile);
> > +
> > +    return 0;
> > +}
> > +
> >  /*
> >   * Local variables:
> >   * mode: C
> > diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
> > index ebe0220..ab4d56c 100644
> > --- a/tools/libxl/xl_cmdtable.c
> > +++ b/tools/libxl/xl_cmdtable.c
> > @@ -494,6 +494,12 @@ struct cmd_spec cmd_table[] = {
> >        "[options]",
> >        "-F                      Run in the foreground",
> >      },
> > +    { "launch-dom0-qemu",
> > +      &main_launch_dom0_qemu, 0, 1,
> > +      "Start qemu process to service dom0 disk backends",
> > +      "[options] [QEMU_PATH]",
> > +      "-p PIDFILE              Write a PIDFILE\n",
> > +    },
> >  };
> >  
> >  int cmdtable_len = sizeof(cmd_table)/sizeof(struct cmd_spec);
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Xen-users] XEN/arm XENFB support
  2013-12-17 15:55       ` Stefano Stabellini
@ 2013-12-17 16:42         ` Stefano Stabellini
  2013-12-17 16:50           ` Ian Campbell
  0 siblings, 1 reply; 8+ messages in thread
From: Stefano Stabellini @ 2013-12-17 16:42 UTC (permalink / raw)
  To: Stefano Stabellini; +Cc: Lars Kurth, xen-users, peter, Ian Campbell, xen-devel

On Tue, 17 Dec 2013, Stefano Stabellini wrote:
> On Tue, 17 Dec 2013, peter wrote:
> > Thank you for the info/patch Ian.
> > With some modifications to Qemu, I managed to cross compile
> > qemu-system-arm with XEN support.
> > Based on version: 1c514a7734b7f98625a0d18d5e8ee7581f26e50c (Merge remote
> > branch 'perard/cpu-hotplug-port-v2' into xen-staging-master-7).
> > And got my Qemu backend working.
> 
> Nice! Could you please post your patch?

Actually I have just tried it out and with the appended QEMU patch works fine.
I'll come up with a proper patch and send it upstream.

diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index f0333a0..e9b1af8 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -409,7 +409,7 @@ static void input_event(struct XenDevice *xendev)
 
 /* -------------------------------------------------------------------- */
 
-static void xenfb_copy_mfns(int mode, int count, unsigned long *dst, void *src)
+static void xenfb_copy_mfns(int mode, int count, xen_pfn_t *dst, void *src)
 {
     uint32_t *src32 = src;
     uint64_t *src64 = src;
@@ -424,8 +424,8 @@ static int xenfb_map_fb(struct XenFB *xenfb)
     struct xenfb_page *page = xenfb->c.page;
     char *protocol = xenfb->c.xendev.protocol;
     int n_fbdirs;
-    unsigned long *pgmfns = NULL;
-    unsigned long *fbmfns = NULL;
+    xen_pfn_t *pgmfns = NULL;
+    xen_pfn_t *fbmfns = NULL;
     void *map, *pd;
     int mode, ret = -1;
 
@@ -483,8 +483,8 @@ static int xenfb_map_fb(struct XenFB *xenfb)
     n_fbdirs = xenfb->fbpages * mode / 8;
     n_fbdirs = (n_fbdirs + (XC_PAGE_SIZE - 1)) / XC_PAGE_SIZE;
 
-    pgmfns = g_malloc0(sizeof(unsigned long) * n_fbdirs);
-    fbmfns = g_malloc0(sizeof(unsigned long) * xenfb->fbpages);
+    pgmfns = g_malloc0(sizeof(xen_pfn_t) * n_fbdirs);
+    fbmfns = g_malloc0(sizeof(xen_pfn_t) * xenfb->fbpages);
 
     xenfb_copy_mfns(mode, n_fbdirs, pgmfns, pd);
     map = xc_map_foreign_pages(xen_xc, xenfb->c.xendev.dom,
diff --git a/xen-all.c b/xen-all.c
index 4a594bd..d45180d 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -381,8 +381,6 @@ static int xen_remove_from_physmap(XenIOState *state,
 
         rc = xc_domain_add_to_physmap(xen_xc, xen_domid, XENMAPSPACE_gmfn, idx, gpfn);
         if (rc) {
-            fprintf(stderr, "add_to_physmap MFN %"PRI_xen_pfn" to PFN %"
-                    PRI_xen_pfn" failed: %d\n", idx, gpfn, rc);
             return -rc;
         }
     }
diff --git a/xen-mapcache.c b/xen-mapcache.c
index eda914a..baea376 100644
--- a/xen-mapcache.c
+++ b/xen-mapcache.c
@@ -33,13 +33,8 @@
 #  define DPRINTF(fmt, ...) do { } while (0)
 #endif
 
-#if defined(__i386__)
 #  define MCACHE_BUCKET_SHIFT 16
 #  define MCACHE_MAX_SIZE     (1UL<<31) /* 2GB Cap */
-#elif defined(__x86_64__)
-#  define MCACHE_BUCKET_SHIFT 20
-#  define MCACHE_MAX_SIZE     (1UL<<35) /* 32GB Cap */
-#endif
 #define MCACHE_BUCKET_SIZE (1UL << MCACHE_BUCKET_SHIFT)
 
 /* This is the size of the virtual address space reserve to QEMU that will not

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [Xen-users] XEN/arm XENFB support
  2013-12-17 16:42         ` Stefano Stabellini
@ 2013-12-17 16:50           ` Ian Campbell
  2013-12-17 16:54             ` Stefano Stabellini
  0 siblings, 1 reply; 8+ messages in thread
From: Ian Campbell @ 2013-12-17 16:50 UTC (permalink / raw)
  To: Stefano Stabellini; +Cc: Lars Kurth, xen-users, peter, xen-devel

On Tue, 2013-12-17 at 16:42 +0000, Stefano Stabellini wrote:

> diff --git a/xen-all.c b/xen-all.c
> index 4a594bd..d45180d 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -381,8 +381,6 @@ static int xen_remove_from_physmap(XenIOState *state,
>  
>          rc = xc_domain_add_to_physmap(xen_xc, xen_domid, XENMAPSPACE_gmfn, idx, gpfn);
>          if (rc) {
> -            fprintf(stderr, "add_to_physmap MFN %"PRI_xen_pfn" to PFN %"
> -                    PRI_xen_pfn" failed: %d\n", idx, gpfn, rc);

This message seemed useful to me...

>              return -rc;
>          }
>      }
> 
> diff --git a/xen-mapcache.c b/xen-mapcache.c
> index eda914a..baea376 100644
> --- a/xen-mapcache.c
> +++ b/xen-mapcache.c
> @@ -33,13 +33,8 @@
>  #  define DPRINTF(fmt, ...) do { } while (0)
>  #endif
>  
> -#if defined(__i386__)
>  #  define MCACHE_BUCKET_SHIFT 16
>  #  define MCACHE_MAX_SIZE     (1UL<<31) /* 2GB Cap */
> -#elif defined(__x86_64__)
> -#  define MCACHE_BUCKET_SHIFT 20
> -#  define MCACHE_MAX_SIZE     (1UL<<35) /* 32GB Cap */
> -#endif

This bit seems a unrelated? Or should it really be adding __arm__ and
__aarch64__ bits and this was just a quick hack?

It'd be good if someone would pick up Daniel De Graaf's frontend patches
(see earlier in the thread) to use grants instead of priv mappings and
implement the matching backend stuff in qemu...

Ian.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Xen-users] XEN/arm XENFB support
  2013-12-17 16:50           ` Ian Campbell
@ 2013-12-17 16:54             ` Stefano Stabellini
  0 siblings, 0 replies; 8+ messages in thread
From: Stefano Stabellini @ 2013-12-17 16:54 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Lars Kurth, xen-users, peter, xen-devel, Stefano Stabellini

On Tue, 17 Dec 2013, Ian Campbell wrote:
> On Tue, 2013-12-17 at 16:42 +0000, Stefano Stabellini wrote:
> 
> > diff --git a/xen-all.c b/xen-all.c
> > index 4a594bd..d45180d 100644
> > --- a/xen-all.c
> > +++ b/xen-all.c
> > @@ -381,8 +381,6 @@ static int xen_remove_from_physmap(XenIOState *state,
> >  
> >          rc = xc_domain_add_to_physmap(xen_xc, xen_domid, XENMAPSPACE_gmfn, idx, gpfn);
> >          if (rc) {
> > -            fprintf(stderr, "add_to_physmap MFN %"PRI_xen_pfn" to PFN %"
> > -                    PRI_xen_pfn" failed: %d\n", idx, gpfn, rc);
> 
> This message seemed useful to me...

Yeah, this is just a debug patch to show the concept. I am cleaning it
up now.


> >              return -rc;
> >          }
> >      }
> > 
> > diff --git a/xen-mapcache.c b/xen-mapcache.c
> > index eda914a..baea376 100644
> > --- a/xen-mapcache.c
> > +++ b/xen-mapcache.c
> > @@ -33,13 +33,8 @@
> >  #  define DPRINTF(fmt, ...) do { } while (0)
> >  #endif
> >  
> > -#if defined(__i386__)
> >  #  define MCACHE_BUCKET_SHIFT 16
> >  #  define MCACHE_MAX_SIZE     (1UL<<31) /* 2GB Cap */
> > -#elif defined(__x86_64__)
> > -#  define MCACHE_BUCKET_SHIFT 20
> > -#  define MCACHE_MAX_SIZE     (1UL<<35) /* 32GB Cap */
> > -#endif
> 
> This bit seems a unrelated? Or should it really be adding __arm__ and
> __aarch64__ bits and this was just a quick hack?

Right, this was a quick hack.


> It'd be good if someone would pick up Daniel De Graaf's frontend patches
> (see earlier in the thread) to use grants instead of priv mappings and
> implement the matching backend stuff in qemu...
> 
> Ian.
> 
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2013-12-17 16:54 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <WC20131216081609.85000C@perkbv.com>
2013-12-16  8:45 ` [Xen-users] XEN/arm XENFB support Lars Kurth
2013-12-16  9:59   ` Ian Campbell
2013-12-17  7:20     ` peter
2013-12-17  9:53       ` Ian Campbell
2013-12-17 15:55       ` Stefano Stabellini
2013-12-17 16:42         ` Stefano Stabellini
2013-12-17 16:50           ` Ian Campbell
2013-12-17 16:54             ` Stefano Stabellini

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.