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
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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 >_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
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);
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);
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:-2These 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 >
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
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 */ > -#endifThis 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.
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. > >
Maybe Matching Threads
- PATCH 0/10: Merge PV framebuffer & console into QEMU
- [PATCH 0/2] fbif: Add offset in resize event
- [PATCH] ioemu: fix xenfb slow case update
- [RFC] PVFB: Add refresh period to XenStore parameters?
- Bug#784880: [PATCH for-4.6] tools: libxl: Handle failure to create qemu dm logfile