* [RFC 0/7] RFC Linux-based QEMU-upstream stub domain
@ 2015-02-04 4:06 Eric Shelton
2015-02-04 4:06 ` [RFC 1/7] linux-stubdomain: Compile QEMU Eric Shelton
` (7 more replies)
0 siblings, 8 replies; 43+ messages in thread
From: Eric Shelton @ 2015-02-04 4:06 UTC (permalink / raw)
To: xen-devel; +Cc: anthony.perard, Eric Shelton, Ian.Campbell, stefano.stabellini
This patch series updates Anthony Perard's original patch series to
bring support for running QEMU upstream as a device model in a
stubdomain by using a Linux-based stubdom, rather than MiniOS as
currently used for QEMU traditional. Anthony posted the original
patch series on April 17, 2013.
The first three patches build Linux 3.17.8 and a disk image for the
stubdomain itself. QEMU is being pulled from the same repo as is
being used for Xen 4.5.0, and some minor patches are being applied.
A new directory is created within xen.git, stubdom-linux. Calling
'make' in this directory will build Linux, QEMU upstream, and an
ext2 disk image. Then a 'make install' will copy the Linux kernel
and disk image into the same directory used for other stubdomain
images, such as MiniOS. This build process has by no means been
integrated with the overall Xen build process. A more refined
process would be expected for release code, such as integration
with configure, eliminating the hard-coded path for 'make install',
and only doing a single download of the QEMU sources.
The last four patches are the libxl support, which allows selecting
between MiniOS/QEMU-traditional and Linux/QEMU-upstream. For
QEMU-upstream, the VM config file would include:
device_model_version = "qemu-xen"
device_model_stubdomain_override = 1
For QEMU-traditional, the VM config file would include:
device_model_version = "qemu-xen-traditional"
device_model_stubdomain_override = 1
There a number of features that are not supported yet:
- video output (e.g., VNC)
- save/restore
- QMP
QMP, or at least part of the QMP protocol, will likely present
some interesting issues. Assumedly, there will be some subset of
QMP commands that will require some coordination between the QEMU
instance running in the stubdomain and a QEMU instance running in
Dom0 (or some other domain).
Other expected tweaks:
- Currently 128MB of memory is being used for the stubdomain. This
is more than needed, but no attempt has been made to find the
appropriate lower limit.
- The kernel config.
- The disk image can be made smaller.
This patch series has been successfully used to run a simple Linux
HVM guest, without the Xen drivers built into the kernel (this is
not meant to imply that the drivers will not work, but was more to
confirm the emulated NIC and disks provided by QEMU worked). Once
booted up, it was possible to successfully SSH into the Linux HVM
guest.
Regards,
Eric Shelton
--
Patches:
[RFC 1/7] linux-stubdomain: Compile QEMU
[RFC 2/7] linux-stubdomain: Compile Linux
[RFC 3/7] linux-stubdomain: Build a disk image
[RFC 4/7] libxl: Add "stubdomain_version" to domain_build_info
[RFC 5/7] libxl: Handle Linux stubdomain specific QEMU options
[RFC 6/7] libxl: Build the domain with a Linux based stubdomain
[RFC 7/7] libxl: Wait for QEMU startup in stubdomain
^ permalink raw reply [flat|nested] 43+ messages in thread
* [RFC 1/7] linux-stubdomain: Compile QEMU
2015-02-04 4:06 [RFC 0/7] RFC Linux-based QEMU-upstream stub domain Eric Shelton
@ 2015-02-04 4:06 ` Eric Shelton
2015-02-06 15:46 ` Stefano Stabellini
2015-02-04 4:06 ` [RFC 2/7] linux-stubdomain: Compile Linux Eric Shelton
` (6 subsequent siblings)
7 siblings, 1 reply; 43+ messages in thread
From: Eric Shelton @ 2015-02-04 4:06 UTC (permalink / raw)
To: xen-devel; +Cc: anthony.perard, Eric Shelton, Ian.Campbell, stefano.stabellini
This patch adds a Makefile which downloads, patches, and compiles
upstream QEMU for a stubdomain based on a linux kernel.
Signed-off-by: Eric Shelton <eshelton@pobox.com>
---
stubdom-linux/.gitignore | 3 ++
stubdom-linux/Makefile | 55 +++++++++++++++++++++++++++++++++++++
stubdom-linux/qemu-configure.patch | 47 +++++++++++++++++++++++++++++++
stubdom-linux/qemu-xen-common.patch | 12 ++++++++
stubdom-linux/qemu-xen-h.patch | 18 ++++++++++++
stubdom-linux/qemu-xen-hvm.patch | 36 ++++++++++++++++++++++++
6 files changed, 171 insertions(+)
create mode 100644 stubdom-linux/.gitignore
create mode 100644 stubdom-linux/Makefile
create mode 100644 stubdom-linux/qemu-configure.patch
create mode 100644 stubdom-linux/qemu-xen-common.patch
create mode 100644 stubdom-linux/qemu-xen-h.patch
create mode 100644 stubdom-linux/qemu-xen-hvm.patch
diff --git a/stubdom-linux/.gitignore b/stubdom-linux/.gitignore
new file mode 100644
index 0000000..1b5ec08
--- /dev/null
+++ b/stubdom-linux/.gitignore
@@ -0,0 +1,3 @@
+/qemu-build/
+/qemu-remote
+/qemu-remote-remote/
diff --git a/stubdom-linux/Makefile b/stubdom-linux/Makefile
new file mode 100644
index 0000000..4e84a61
--- /dev/null
+++ b/stubdom-linux/Makefile
@@ -0,0 +1,55 @@
+XEN_ROOT = $(CURDIR)/..
+
+-include $(XEN_ROOT)/config/Tools.mk
+include $(XEN_ROOT)/Config.mk
+
+# Qemu tree used
+QEMU_TREE=git://xenbits.xen.org/qemu-upstream-4.5-testing.git
+QEMU_BRANCH=qemu-xen-4.5.0
+
+all:
+
+qemu-build/Makefile:
+ export GIT=$(GIT); \
+ $(XEN_ROOT)/scripts/git-checkout.sh $(QEMU_TREE) $(QEMU_BRANCH) qemu-remote
+ cd qemu-remote && patch -p1 < ../qemu-configure.patch
+ cd qemu-remote && patch -p1 < ../qemu-xen-common.patch
+ cd qemu-remote && patch -p1 < ../qemu-xen-h.patch
+ cd qemu-remote && patch -p1 < ../qemu-xen-hvm.patch
+ mkdir -p qemu-build
+ cd qemu-build && ../qemu-remote/configure \
+ --target-list=i386-softmmu \
+ --enable-xen \
+ --extra-cflags="-I$(XEN_ROOT)/tools/include \
+ -I$(XEN_ROOT)/tools/libxc \
+ -I$(XEN_ROOT)/tools/xenstore \
+ -I$(XEN_ROOT)/tools/xenstore/compat \
+ -DDEBUG_XEN" \
+ --extra-ldflags="-L$(XEN_ROOT)/tools/libxc -L$(XEN_ROOT)/tools/xenstore" \
+ --disable-werror \
+ --disable-sdl \
+ --disable-kvm \
+ --disable-gtk \
+ --disable-fdt \
+ --disable-bluez \
+ --disable-libusb \
+ --disable-slirp \
+ --disable-pie \
+ --disable-docs \
+ --disable-vhost-net \
+ --disable-spice \
+ --disable-guest-agent \
+ --audio-drv-list= \
+ --disable-smartcard-nss \
+ --enable-stubdom \
+ --disable-vnc \
+ --disable-spice \
+ --enable-trace-backend=stderr \
+ --disable-curses \
+ --python=$(PYTHON) \
+ --prefix=
+
+.PHONY:qemu-build
+qemu-build: qemu-build/Makefile
+qemu-build/i386-softmmu/qemu-system-i386: qemu-build
+ $(MAKE) -C qemu-build
diff --git a/stubdom-linux/qemu-configure.patch b/stubdom-linux/qemu-configure.patch
new file mode 100644
index 0000000..b93132d
--- /dev/null
+++ b/stubdom-linux/qemu-configure.patch
@@ -0,0 +1,47 @@
+--- a/configure 2015-01-21 23:48:23.763333326 -0500
++++ b/configure 2015-01-21 23:52:30.326666664 -0500
+@@ -300,6 +300,7 @@
+ libusb=""
+ usb_redir=""
+ glx=""
++stubdom="no"
+ zlib="yes"
+ lzo="no"
+ snappy="no"
+@@ -1021,6 +1022,8 @@
+ ;;
+ --enable-usb-redir) usb_redir="yes"
+ ;;
++ --enable-stubdom) stubdom="yes"
++ ;;
+ --disable-zlib-test) zlib="no"
+ ;;
+ --enable-lzo) lzo="yes"
+@@ -1329,6 +1332,7 @@
+ --enable-usb-redir enable usb network redirection support
+ --enable-lzo enable the support of lzo compression library
+ --enable-snappy enable the support of snappy compression library
++ --enable-stubdom enable building the ioemu-stubdom
+ --disable-guest-agent disable building of the QEMU Guest Agent
+ --enable-guest-agent enable building of the QEMU Guest Agent
+ --with-vss-sdk=SDK-path enable Windows VSS support in QEMU Guest Agent
+@@ -4122,6 +4126,7 @@
+ echo "Target Sparc Arch $sparc_cpu"
+ fi
+ echo "xen support $xen"
++echo "stubdom support $stubdom"
+ echo "brlapi support $brlapi"
+ echo "bluez support $bluez"
+ echo "Documentation $docs"
+@@ -4553,6 +4558,11 @@
+ echo "RBD_LIBS=$rbd_libs" >> $config_host_mak
+ fi
+
++# stubdom support
++if test "$stubdom" = "yes"; then
++ echo "CONFIG_STUBDOM=y" >> $config_host_mak
++fi
++
+ echo "CONFIG_COROUTINE_BACKEND=$coroutine" >> $config_host_mak
+ if test "$coroutine_pool" = "yes" ; then
+ echo "CONFIG_COROUTINE_POOL=1" >> $config_host_mak
diff --git a/stubdom-linux/qemu-xen-common.patch b/stubdom-linux/qemu-xen-common.patch
new file mode 100644
index 0000000..b473e36
--- /dev/null
+++ b/stubdom-linux/qemu-xen-common.patch
@@ -0,0 +1,12 @@
+--- a/xen-common.c 2015-01-25 20:42:36.329999998 -0500
++++ b/xen-common.c 2015-01-25 20:43:20.346666663 -0500
+@@ -92,7 +92,8 @@
+ exit(1);
+ }
+
+- snprintf(path, sizeof (path), "device-model/%u/state", xen_domid);
++ snprintf(path, sizeof (path),
++ "/local/domain/0/device-model/%u/state", xen_domid);
+ if (!xs_write(xs, XBT_NULL, path, state, strlen(state))) {
+ fprintf(stderr, "error recording dm state\n");
+ exit(1);
diff --git a/stubdom-linux/qemu-xen-h.patch b/stubdom-linux/qemu-xen-h.patch
new file mode 100644
index 0000000..262b1d1
--- /dev/null
+++ b/stubdom-linux/qemu-xen-h.patch
@@ -0,0 +1,18 @@
+--- a/include/hw/xen/xen.h 2015-01-21 23:54:36.856666662 -0500
++++ b/include/hw/xen/xen.h 2015-01-21 23:55:39.356666667 -0500
+@@ -28,6 +28,15 @@
+ return xen_allowed;
+ }
+
++static inline int xen_stubdom_enable(void)
++{
++#ifdef CONFIG_STUBDOM
++ return 1;
++#else
++ return 0;
++#endif
++}
++
+ int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num);
+ void xen_piix3_set_irq(void *opaque, int irq_num, int level);
+ void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len);
diff --git a/stubdom-linux/qemu-xen-hvm.patch b/stubdom-linux/qemu-xen-hvm.patch
new file mode 100644
index 0000000..ac6a53f
--- /dev/null
+++ b/stubdom-linux/qemu-xen-hvm.patch
@@ -0,0 +1,36 @@
+--- a/xen-hvm.c 2015-01-21 22:32:42.999999995 -0500
++++ b/xen-hvm.c 2015-01-21 22:35:17.633333330 -0500
+@@ -1008,6 +1008,10 @@
+ state->wakeup.notify = xen_wakeup_notifier;
+ qemu_register_wakeup_notifier(&state->wakeup);
+
++ if (xen_stubdom_enable()) {
++ xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_DM_DOMAIN, DOMID_SELF);
++ }
++
+ xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_IOREQ_PFN, &ioreq_pfn);
+ DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
+ state->shared_page = xc_map_foreign_range(xen_xc, xen_domid, XC_PAGE_SIZE,
+@@ -1063,6 +1067,7 @@
+ memory_listener_register(&state->memory_listener, &address_space_memory);
+ state->log_for_dirtybit = NULL;
+
++#ifndef CONFIG_STUBDOM
+ /* Initialize backend core & drivers */
+ if (xen_be_init() != 0) {
+ fprintf(stderr, "%s: xen backend core setup failed\n", __FUNCTION__);
+@@ -1071,6 +1076,14 @@
+ xen_be_register("console", &xen_console_ops);
+ xen_be_register("vkbd", &xen_kbdmouse_ops);
+ xen_be_register("qdisk", &xen_blkdev_ops);
++#else
++ xenstore = xs_daemon_open();
++ if (!xenstore) {
++ xen_be_printf(NULL, 0, "can't connect to xenstored\n");
++ return -1;
++ }
++#endif
++
+ xen_read_physmap(state);
+
+ return 0;
--
1.8.5.5
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [RFC 2/7] linux-stubdomain: Compile Linux
2015-02-04 4:06 [RFC 0/7] RFC Linux-based QEMU-upstream stub domain Eric Shelton
2015-02-04 4:06 ` [RFC 1/7] linux-stubdomain: Compile QEMU Eric Shelton
@ 2015-02-04 4:06 ` Eric Shelton
2015-02-06 15:51 ` Stefano Stabellini
2015-02-04 4:06 ` [RFC 3/7] linux-stubdomain: Build a disk image Eric Shelton
` (5 subsequent siblings)
7 siblings, 1 reply; 43+ messages in thread
From: Eric Shelton @ 2015-02-04 4:06 UTC (permalink / raw)
To: xen-devel; +Cc: anthony.perard, Eric Shelton, Ian.Campbell, stefano.stabellini
This patch adds rules to the Makefile to retrieve Linux and build a
minimal kernel for the stubdomain. Using Linux kernel 3.17.8.
In order to work as a stubdomain, two patches are applied to the Linux
kernel source.
Signed-off-by: Eric Shelton <eshelton@pobox.com>
---
stubdom-linux/.gitignore | 3 +
...-Don-t-write-in-the-type-node-in-xenstore.patch | 30 +
stubdom-linux/0002-fix-remap_area_mfn_pte_fn.patch | 38 +
stubdom-linux/Makefile | 24 +-
stubdom-linux/stubdom-linux-config-64b | 1510 ++++++++++++++++++++
5 files changed, 1604 insertions(+), 1 deletion(-)
create mode 100644 stubdom-linux/0001-hvc_xen-Don-t-write-in-the-type-node-in-xenstore.patch
create mode 100644 stubdom-linux/0002-fix-remap_area_mfn_pte_fn.patch
create mode 100644 stubdom-linux/stubdom-linux-config-64b
diff --git a/stubdom-linux/.gitignore b/stubdom-linux/.gitignore
index 1b5ec08..891f0c8 100644
--- a/stubdom-linux/.gitignore
+++ b/stubdom-linux/.gitignore
@@ -1,3 +1,6 @@
/qemu-build/
/qemu-remote
/qemu-remote-remote/
+/linux-*.tar.xz
+/linux-*/
+/vmlinuz-stubdom
diff --git a/stubdom-linux/0001-hvc_xen-Don-t-write-in-the-type-node-in-xenstore.patch b/stubdom-linux/0001-hvc_xen-Don-t-write-in-the-type-node-in-xenstore.patch
new file mode 100644
index 0000000..24fac2f
--- /dev/null
+++ b/stubdom-linux/0001-hvc_xen-Don-t-write-in-the-type-node-in-xenstore.patch
@@ -0,0 +1,30 @@
+From bc93f3b6d97b1376a5f5d1dbb746d82f8003e184 Mon Sep 17 00:00:00 2001
+From: Anthony PERARD <anthony.perard@citrix.com>
+Date: Tue, 20 Aug 2013 17:07:53 +0100
+Subject: [PATCH] hvc_xen: Don't write in the type node in xenstore.
+
+Due to a recent commit in the Xen Project, writing to "type" is not
+allowed any more.
+
+Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
+---
+ drivers/tty/hvc/hvc_xen.c | 3 ---
+ 1 file changed, 3 deletions(-)
+
+diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
+index 682210d..032add4 100644
+--- a/drivers/tty/hvc/hvc_xen.c
++++ b/drivers/tty/hvc/hvc_xen.c
+@@ -402,9 +402,6 @@ static int xencons_connect_backend(struct xenbus_device *dev,
+ evtchn);
+ if (ret)
+ goto error_xenbus;
+- ret = xenbus_printf(xbt, dev->nodename, "type", "ioemu");
+- if (ret)
+- goto error_xenbus;
+ ret = xenbus_transaction_end(xbt, 0);
+ if (ret) {
+ if (ret == -EAGAIN)
+--
+Anthony PERARD
+
diff --git a/stubdom-linux/0002-fix-remap_area_mfn_pte_fn.patch b/stubdom-linux/0002-fix-remap_area_mfn_pte_fn.patch
new file mode 100644
index 0000000..e26b0da
--- /dev/null
+++ b/stubdom-linux/0002-fix-remap_area_mfn_pte_fn.patch
@@ -0,0 +1,38 @@
+From 61cd574f29f41046f1c709cfa9da118156babf83 Mon Sep 17 00:00:00 2001
+From: Anthony PERARD <anthony.perard@citrix.com>
+Date: Fri, 1 Jun 2012 15:47:01 +0100
+Subject: [PATCH 2/2] fix/remap_area_mfn_pte_fn
+
+---
+ arch/x86/xen/mmu.c | 13 ++++++++++++-
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
+index 69f5857..999fc82 100644
+--- a/arch/x86/xen/mmu.c
++++ b/arch/x86/xen/mmu.c
+@@ -2606,7 +2606,20 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
+ unsigned long addr, void *data)
+ {
+ struct remap_data *rmd = data;
+- pte_t pte = pte_mkspecial(mfn_pte(rmd->mfn++, rmd->prot));
++
++ /* Use the native_make_pte function because we are sure we don't
++ * have to do any pfn->mfn translations but at the same time we
++ * could in a stubdom so xen_initial_domain() would return false. */
++ pte_t pte = pte_mkspecial(native_make_pte(((phys_addr_t)(rmd->mfn++) << PAGE_SHIFT)
++ | massage_pgprot(rmd->prot)));
++ pteval_t val = pte_val_ma(pte);
++
++#if 0
++ if (pat_enabled && !WARN_ON(val & _PAGE_PAT)) {
++ if ((val & (_PAGE_PCD | _PAGE_PWT)) == _PAGE_PWT)
++ val = (val & ~(_PAGE_PCD | _PAGE_PWT)) | _PAGE_PAT;
++ }
++#endif
+
+ rmd->mmu_update->ptr = virt_to_machine(ptep).maddr;
+ rmd->mmu_update->val = pte_val_ma(pte);
+--
+Anthony PERARD
+
diff --git a/stubdom-linux/Makefile b/stubdom-linux/Makefile
index 4e84a61..31bfbee 100644
--- a/stubdom-linux/Makefile
+++ b/stubdom-linux/Makefile
@@ -7,7 +7,12 @@ include $(XEN_ROOT)/Config.mk
QEMU_TREE=git://xenbits.xen.org/qemu-upstream-4.5-testing.git
QEMU_BRANCH=qemu-xen-4.5.0
-all:
+# Linux Kernel version used
+LINUX_V=linux-3.17.8
+VMLINUZ=$(LINUX_V)/arch/x86/boot/bzImage
+LINUX_URL=ftp://ftp.kernel.org/pub/linux/kernel/v3.x/$(LINUX_V).tar.xz
+
+all: $(VMLINUZ)
qemu-build/Makefile:
export GIT=$(GIT); \
@@ -53,3 +58,20 @@ qemu-build/Makefile:
qemu-build: qemu-build/Makefile
qemu-build/i386-softmmu/qemu-system-i386: qemu-build
$(MAKE) -C qemu-build
+
+$(LINUX_V).tar.xz:
+ $(FETCHER) $@ $(LINUX_URL)
+
+$(LINUX_V)/Makefile $(LINUX_V)/.config: $(LINUX_V).tar.xz
+ rm -rf $(LINUX_V)
+ tar xf $(LINUX_V).tar.xz
+ # Temp patches
+ patch -d $(LINUX_V) -p1 -i ../0002-fix-remap_area_mfn_pte_fn.patch
+ patch -d $(LINUX_V) -p1 -i ../0001-hvc_xen-Don-t-write-in-the-type-node-in-xenstore.patch
+ cp stubdom-linux-config-64b $(LINUX_V)/.config
+
+$(VMLINUZ): $(LINUX_V)/.config
+ $(MAKE) -C $(LINUX_V)
+
+install: $(VMLINUZ)
+ cp -f $(VMLINUZ) $(DESTDIR)/usr/local/lib/xen/boot/vmlinuz-stubdom
diff --git a/stubdom-linux/stubdom-linux-config-64b b/stubdom-linux/stubdom-linux-config-64b
new file mode 100644
index 0000000..d69f374
--- /dev/null
+++ b/stubdom-linux/stubdom-linux-config-64b
@@ -0,0 +1,1510 @@
+#
+# Automatically generated file; DO NOT EDIT.
+# Linux/x86 3.17.8 Kernel Configuration
+#
+CONFIG_64BIT=y
+CONFIG_X86_64=y
+CONFIG_X86=y
+CONFIG_INSTRUCTION_DECODER=y
+CONFIG_OUTPUT_FORMAT="elf64-x86-64"
+CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
+CONFIG_LOCKDEP_SUPPORT=y
+CONFIG_STACKTRACE_SUPPORT=y
+CONFIG_HAVE_LATENCYTOP_SUPPORT=y
+CONFIG_MMU=y
+CONFIG_NEED_DMA_MAP_STATE=y
+CONFIG_NEED_SG_DMA_LENGTH=y
+CONFIG_GENERIC_ISA_DMA=y
+CONFIG_GENERIC_BUG=y
+CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
+CONFIG_GENERIC_HWEIGHT=y
+CONFIG_ARCH_MAY_HAVE_PC_FDC=y
+CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_ARCH_HAS_CPU_RELAX=y
+CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
+CONFIG_HAVE_SETUP_PER_CPU_AREA=y
+CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
+CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
+CONFIG_ARCH_HIBERNATION_POSSIBLE=y
+CONFIG_ARCH_SUSPEND_POSSIBLE=y
+CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
+CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
+CONFIG_ZONE_DMA32=y
+CONFIG_AUDIT_ARCH=y
+CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
+CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
+CONFIG_X86_64_SMP=y
+CONFIG_X86_HT=y
+CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11"
+CONFIG_ARCH_SUPPORTS_UPROBES=y
+CONFIG_FIX_EARLYCON_MEM=y
+CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
+CONFIG_IRQ_WORK=y
+CONFIG_BUILDTIME_EXTABLE_SORT=y
+
+#
+# General setup
+#
+CONFIG_INIT_ENV_ARG_LIMIT=32
+CONFIG_CROSS_COMPILE=""
+# CONFIG_COMPILE_TEST is not set
+CONFIG_LOCALVERSION="-XenStubdom"
+# CONFIG_LOCALVERSION_AUTO is not set
+CONFIG_HAVE_KERNEL_GZIP=y
+CONFIG_HAVE_KERNEL_BZIP2=y
+CONFIG_HAVE_KERNEL_LZMA=y
+CONFIG_HAVE_KERNEL_XZ=y
+CONFIG_HAVE_KERNEL_LZO=y
+CONFIG_HAVE_KERNEL_LZ4=y
+CONFIG_KERNEL_GZIP=y
+# CONFIG_KERNEL_BZIP2 is not set
+# CONFIG_KERNEL_LZMA is not set
+# CONFIG_KERNEL_XZ is not set
+# CONFIG_KERNEL_LZO is not set
+# CONFIG_KERNEL_LZ4 is not set
+CONFIG_DEFAULT_HOSTNAME="stubdom"
+# CONFIG_SWAP is not set
+# CONFIG_SYSVIPC is not set
+# CONFIG_POSIX_MQUEUE is not set
+# CONFIG_CROSS_MEMORY_ATTACH is not set
+# CONFIG_FHANDLE is not set
+CONFIG_USELIB=y
+# CONFIG_AUDIT is not set
+CONFIG_HAVE_ARCH_AUDITSYSCALL=y
+
+#
+# IRQ subsystem
+#
+CONFIG_GENERIC_IRQ_PROBE=y
+CONFIG_GENERIC_IRQ_SHOW=y
+CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y
+CONFIG_GENERIC_PENDING_IRQ=y
+CONFIG_IRQ_DOMAIN=y
+CONFIG_IRQ_FORCED_THREADING=y
+CONFIG_SPARSE_IRQ=y
+CONFIG_CLOCKSOURCE_WATCHDOG=y
+CONFIG_ARCH_CLOCKSOURCE_DATA=y
+CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
+CONFIG_GENERIC_TIME_VSYSCALL=y
+CONFIG_GENERIC_CLOCKEVENTS=y
+CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
+CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
+CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
+CONFIG_GENERIC_CMOS_UPDATE=y
+
+#
+# Timers subsystem
+#
+CONFIG_TICK_ONESHOT=y
+CONFIG_NO_HZ_COMMON=y
+# CONFIG_HZ_PERIODIC is not set
+CONFIG_NO_HZ_IDLE=y
+# CONFIG_NO_HZ_FULL is not set
+# CONFIG_NO_HZ is not set
+# CONFIG_HIGH_RES_TIMERS is not set
+
+#
+# CPU/Task time and stats accounting
+#
+CONFIG_VIRT_CPU_ACCOUNTING=y
+# CONFIG_TICK_CPU_ACCOUNTING is not set
+CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
+# CONFIG_IRQ_TIME_ACCOUNTING is not set
+# CONFIG_BSD_PROCESS_ACCT is not set
+# CONFIG_TASKSTATS is not set
+
+#
+# RCU Subsystem
+#
+CONFIG_TREE_RCU=y
+# CONFIG_PREEMPT_RCU is not set
+CONFIG_RCU_STALL_COMMON=y
+CONFIG_CONTEXT_TRACKING=y
+# CONFIG_RCU_USER_QS is not set
+# CONFIG_CONTEXT_TRACKING_FORCE is not set
+CONFIG_RCU_FANOUT=64
+CONFIG_RCU_FANOUT_LEAF=16
+# CONFIG_RCU_FANOUT_EXACT is not set
+# CONFIG_RCU_FAST_NO_HZ is not set
+# CONFIG_TREE_RCU_TRACE is not set
+# CONFIG_RCU_NOCB_CPU is not set
+# CONFIG_BUILD_BIN2C is not set
+# CONFIG_IKCONFIG is not set
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
+CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
+CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
+CONFIG_ARCH_SUPPORTS_INT128=y
+CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
+# CONFIG_CGROUPS is not set
+# CONFIG_CHECKPOINT_RESTORE is not set
+# CONFIG_NAMESPACES is not set
+# CONFIG_SCHED_AUTOGROUP is not set
+CONFIG_SYSFS_DEPRECATED=y
+# CONFIG_SYSFS_DEPRECATED_V2 is not set
+# CONFIG_RELAY is not set
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE=""
+CONFIG_RD_GZIP=y
+CONFIG_RD_BZIP2=y
+CONFIG_RD_LZMA=y
+CONFIG_RD_XZ=y
+CONFIG_RD_LZO=y
+CONFIG_RD_LZ4=y
+# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
+CONFIG_ANON_INODES=y
+CONFIG_SYSCTL_EXCEPTION_TRACE=y
+CONFIG_HAVE_PCSPKR_PLATFORM=y
+CONFIG_EXPERT=y
+CONFIG_SGETMASK_SYSCALL=y
+CONFIG_SYSFS_SYSCALL=y
+CONFIG_KALLSYMS=y
+# CONFIG_KALLSYMS_ALL is not set
+CONFIG_PRINTK=y
+CONFIG_BUG=y
+CONFIG_PCSPKR_PLATFORM=y
+CONFIG_BASE_FULL=y
+CONFIG_FUTEX=y
+CONFIG_EPOLL=y
+CONFIG_SIGNALFD=y
+CONFIG_TIMERFD=y
+CONFIG_EVENTFD=y
+CONFIG_SHMEM=y
+CONFIG_AIO=y
+# CONFIG_EMBEDDED is not set
+CONFIG_HAVE_PERF_EVENTS=y
+
+#
+# Kernel Performance Events And Counters
+#
+CONFIG_PERF_EVENTS=y
+# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
+# CONFIG_VM_EVENT_COUNTERS is not set
+CONFIG_SLUB_DEBUG=y
+CONFIG_COMPAT_BRK=y
+# CONFIG_SLAB is not set
+CONFIG_SLUB=y
+# CONFIG_SLOB is not set
+CONFIG_SLUB_CPU_PARTIAL=y
+# CONFIG_PROFILING is not set
+CONFIG_HAVE_OPROFILE=y
+CONFIG_OPROFILE_NMI_TIMER=y
+CONFIG_JUMP_LABEL=y
+# CONFIG_UPROBES is not set
+# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
+CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
+CONFIG_ARCH_USE_BUILTIN_BSWAP=y
+CONFIG_HAVE_IOREMAP_PROT=y
+CONFIG_HAVE_KPROBES=y
+CONFIG_HAVE_KRETPROBES=y
+CONFIG_HAVE_OPTPROBES=y
+CONFIG_HAVE_KPROBES_ON_FTRACE=y
+CONFIG_HAVE_ARCH_TRACEHOOK=y
+CONFIG_HAVE_DMA_ATTRS=y
+CONFIG_HAVE_DMA_CONTIGUOUS=y
+CONFIG_GENERIC_SMP_IDLE_THREAD=y
+CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
+CONFIG_HAVE_DMA_API_DEBUG=y
+CONFIG_HAVE_HW_BREAKPOINT=y
+CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
+CONFIG_HAVE_USER_RETURN_NOTIFIER=y
+CONFIG_HAVE_PERF_EVENTS_NMI=y
+CONFIG_HAVE_PERF_REGS=y
+CONFIG_HAVE_PERF_USER_STACK_DUMP=y
+CONFIG_HAVE_ARCH_JUMP_LABEL=y
+CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
+CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
+CONFIG_HAVE_CMPXCHG_LOCAL=y
+CONFIG_HAVE_CMPXCHG_DOUBLE=y
+CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
+CONFIG_HAVE_CC_STACKPROTECTOR=y
+CONFIG_CC_STACKPROTECTOR=y
+# CONFIG_CC_STACKPROTECTOR_NONE is not set
+CONFIG_CC_STACKPROTECTOR_REGULAR=y
+# CONFIG_CC_STACKPROTECTOR_STRONG is not set
+CONFIG_HAVE_CONTEXT_TRACKING=y
+CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y
+CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
+CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
+CONFIG_HAVE_ARCH_SOFT_DIRTY=y
+CONFIG_MODULES_USE_ELF_RELA=y
+CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK=y
+
+#
+# GCOV-based kernel profiling
+#
+# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
+CONFIG_SLABINFO=y
+CONFIG_RT_MUTEXES=y
+CONFIG_BASE_SMALL=0
+# CONFIG_MODULES is not set
+CONFIG_STOP_MACHINE=y
+CONFIG_BLOCK=y
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_BLK_DEV_BSGLIB is not set
+# CONFIG_BLK_DEV_INTEGRITY is not set
+CONFIG_BLK_CMDLINE_PARSER=y
+
+#
+# Partition Types
+#
+# CONFIG_PARTITION_ADVANCED is not set
+CONFIG_MSDOS_PARTITION=y
+CONFIG_EFI_PARTITION=y
+
+#
+# IO Schedulers
+#
+CONFIG_IOSCHED_NOOP=y
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+CONFIG_DEFAULT_NOOP=y
+CONFIG_DEFAULT_IOSCHED="noop"
+CONFIG_UNINLINE_SPIN_UNLOCK=y
+CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
+CONFIG_INLINE_READ_UNLOCK=y
+CONFIG_INLINE_READ_UNLOCK_IRQ=y
+CONFIG_INLINE_WRITE_UNLOCK=y
+CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
+CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
+CONFIG_MUTEX_SPIN_ON_OWNER=y
+CONFIG_RWSEM_SPIN_ON_OWNER=y
+CONFIG_ARCH_USE_QUEUE_RWLOCK=y
+CONFIG_QUEUE_RWLOCK=y
+CONFIG_FREEZER=y
+
+#
+# Processor type and features
+#
+CONFIG_ZONE_DMA=y
+CONFIG_SMP=y
+CONFIG_X86_MPPARSE=y
+# CONFIG_X86_EXTENDED_PLATFORM is not set
+# CONFIG_SCHED_OMIT_FRAME_POINTER is not set
+CONFIG_HYPERVISOR_GUEST=y
+CONFIG_PARAVIRT=y
+CONFIG_PARAVIRT_DEBUG=y
+CONFIG_PARAVIRT_SPINLOCKS=y
+CONFIG_XEN=y
+CONFIG_XEN_MAX_DOMAIN_MEMORY=500
+CONFIG_XEN_SAVE_RESTORE=y
+# CONFIG_KVM_GUEST is not set
+# CONFIG_PARAVIRT_TIME_ACCOUNTING is not set
+CONFIG_PARAVIRT_CLOCK=y
+CONFIG_NO_BOOTMEM=y
+# CONFIG_MEMTEST is not set
+# CONFIG_MK8 is not set
+# CONFIG_MPSC is not set
+# CONFIG_MCORE2 is not set
+# CONFIG_MATOM is not set
+CONFIG_GENERIC_CPU=y
+CONFIG_X86_INTERNODE_CACHE_SHIFT=6
+CONFIG_X86_L1_CACHE_SHIFT=6
+CONFIG_X86_TSC=y
+CONFIG_X86_CMPXCHG64=y
+CONFIG_X86_CMOV=y
+CONFIG_X86_MINIMUM_CPU_FAMILY=64
+CONFIG_X86_DEBUGCTLMSR=y
+# CONFIG_PROCESSOR_SELECT is not set
+CONFIG_CPU_SUP_INTEL=y
+CONFIG_CPU_SUP_AMD=y
+CONFIG_CPU_SUP_CENTAUR=y
+CONFIG_HPET_TIMER=y
+CONFIG_DMI=y
+CONFIG_SWIOTLB=y
+CONFIG_IOMMU_HELPER=y
+# CONFIG_MAXSMP is not set
+CONFIG_NR_CPUS=8
+# CONFIG_SCHED_SMT is not set
+CONFIG_SCHED_MC=y
+CONFIG_PREEMPT_NONE=y
+# CONFIG_PREEMPT_VOLUNTARY is not set
+# CONFIG_PREEMPT is not set
+CONFIG_X86_LOCAL_APIC=y
+CONFIG_X86_IO_APIC=y
+# CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set
+# CONFIG_X86_MCE is not set
+CONFIG_X86_16BIT=y
+CONFIG_X86_ESPFIX64=y
+# CONFIG_I8K is not set
+# CONFIG_MICROCODE is not set
+# CONFIG_MICROCODE_INTEL_EARLY is not set
+# CONFIG_MICROCODE_AMD_EARLY is not set
+# CONFIG_X86_MSR is not set
+# CONFIG_X86_CPUID is not set
+CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
+CONFIG_ARCH_DMA_ADDR_T_64BIT=y
+# CONFIG_DIRECT_GBPAGES is not set
+# CONFIG_NUMA is not set
+CONFIG_ARCH_SPARSEMEM_ENABLE=y
+CONFIG_ARCH_SPARSEMEM_DEFAULT=y
+CONFIG_ARCH_SELECT_MEMORY_MODEL=y
+CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
+CONFIG_SELECT_MEMORY_MODEL=y
+CONFIG_SPARSEMEM_MANUAL=y
+CONFIG_SPARSEMEM=y
+CONFIG_HAVE_MEMORY_PRESENT=y
+CONFIG_SPARSEMEM_EXTREME=y
+CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
+CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y
+CONFIG_SPARSEMEM_VMEMMAP=y
+CONFIG_HAVE_MEMBLOCK=y
+CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
+CONFIG_ARCH_DISCARD_MEMBLOCK=y
+# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
+# CONFIG_MEMORY_HOTPLUG is not set
+CONFIG_PAGEFLAGS_EXTENDED=y
+CONFIG_SPLIT_PTLOCK_CPUS=4
+CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y
+# CONFIG_COMPACTION is not set
+CONFIG_PHYS_ADDR_T_64BIT=y
+CONFIG_ZONE_DMA_FLAG=1
+CONFIG_BOUNCE=y
+CONFIG_VIRT_TO_BUS=y
+CONFIG_MMU_NOTIFIER=y
+# CONFIG_KSM is not set
+CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
+# CONFIG_TRANSPARENT_HUGEPAGE is not set
+# CONFIG_CLEANCACHE is not set
+# CONFIG_CMA is not set
+# CONFIG_ZPOOL is not set
+# CONFIG_ZBUD is not set
+# CONFIG_ZSMALLOC is not set
+CONFIG_GENERIC_EARLY_IOREMAP=y
+# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
+CONFIG_X86_RESERVE_LOW=32
+CONFIG_MTRR=y
+# CONFIG_MTRR_SANITIZER is not set
+CONFIG_X86_PAT=y
+CONFIG_ARCH_USES_PG_UNCACHED=y
+CONFIG_ARCH_RANDOM=y
+# CONFIG_X86_SMAP is not set
+# CONFIG_SECCOMP is not set
+# CONFIG_HZ_100 is not set
+CONFIG_HZ_250=y
+# CONFIG_HZ_300 is not set
+# CONFIG_HZ_1000 is not set
+CONFIG_HZ=250
+# CONFIG_SCHED_HRTICK is not set
+# CONFIG_KEXEC is not set
+# CONFIG_CRASH_DUMP is not set
+CONFIG_PHYSICAL_START=0x1000000
+CONFIG_RELOCATABLE=y
+# CONFIG_RANDOMIZE_BASE is not set
+CONFIG_PHYSICAL_ALIGN=0x1000000
+CONFIG_HOTPLUG_CPU=y
+# CONFIG_BOOTPARAM_HOTPLUG_CPU0 is not set
+# CONFIG_DEBUG_HOTPLUG_CPU0 is not set
+# CONFIG_CMDLINE_BOOL is not set
+CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
+
+#
+# Power management and ACPI options
+#
+# CONFIG_SUSPEND is not set
+CONFIG_HIBERNATE_CALLBACKS=y
+CONFIG_PM_SLEEP=y
+CONFIG_PM_SLEEP_SMP=y
+# CONFIG_PM_AUTOSLEEP is not set
+# CONFIG_PM_WAKELOCKS is not set
+# CONFIG_PM_RUNTIME is not set
+CONFIG_PM=y
+# CONFIG_PM_DEBUG is not set
+# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
+# CONFIG_SFI is not set
+
+#
+# CPU Frequency scaling
+#
+# CONFIG_CPU_FREQ is not set
+
+#
+# CPU Idle
+#
+# CONFIG_CPU_IDLE is not set
+# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
+
+#
+# Memory power savings
+#
+# CONFIG_I7300_IDLE is not set
+
+#
+# Bus options (PCI etc.)
+#
+# CONFIG_PCI is not set
+CONFIG_PCI_LABEL=y
+CONFIG_ISA_DMA_API=y
+# CONFIG_PCCARD is not set
+CONFIG_X86_SYSFB=y
+
+#
+# Executable file formats / Emulations
+#
+CONFIG_BINFMT_ELF=y
+CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
+CONFIG_BINFMT_SCRIPT=y
+# CONFIG_HAVE_AOUT is not set
+# CONFIG_BINFMT_MISC is not set
+# CONFIG_COREDUMP is not set
+# CONFIG_IA32_EMULATION is not set
+CONFIG_X86_DEV_DMA_OPS=y
+CONFIG_NET=y
+
+#
+# Networking options
+#
+CONFIG_PACKET=y
+# CONFIG_PACKET_DIAG is not set
+CONFIG_UNIX=y
+# CONFIG_UNIX_DIAG is not set
+# CONFIG_XFRM_USER is not set
+# CONFIG_NET_KEY is not set
+CONFIG_INET=y
+# CONFIG_IP_MULTICAST is not set
+# CONFIG_IP_ADVANCED_ROUTER is not set
+# CONFIG_IP_PNP is not set
+# CONFIG_NET_IPIP is not set
+# CONFIG_NET_IPGRE_DEMUX is not set
+# CONFIG_NET_IP_TUNNEL is not set
+# CONFIG_SYN_COOKIES is not set
+# CONFIG_NET_UDP_TUNNEL is not set
+# CONFIG_INET_AH is not set
+# CONFIG_INET_ESP is not set
+# CONFIG_INET_IPCOMP is not set
+# CONFIG_INET_XFRM_TUNNEL is not set
+# CONFIG_INET_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+# CONFIG_INET_DIAG is not set
+# CONFIG_TCP_CONG_ADVANCED is not set
+CONFIG_TCP_CONG_CUBIC=y
+CONFIG_DEFAULT_TCP_CONG="cubic"
+# CONFIG_TCP_MD5SIG is not set
+# CONFIG_IPV6 is not set
+# CONFIG_NETWORK_SECMARK is not set
+# CONFIG_NET_PTP_CLASSIFY is not set
+# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
+# CONFIG_NETFILTER is not set
+# CONFIG_IP_DCCP is not set
+# CONFIG_IP_SCTP is not set
+# CONFIG_RDS is not set
+# CONFIG_TIPC is not set
+# CONFIG_ATM is not set
+# CONFIG_L2TP is not set
+CONFIG_STP=y
+CONFIG_BRIDGE=y
+# CONFIG_BRIDGE_IGMP_SNOOPING is not set
+CONFIG_HAVE_NET_DSA=y
+# CONFIG_VLAN_8021Q is not set
+# CONFIG_DECNET is not set
+CONFIG_LLC=y
+# CONFIG_LLC2 is not set
+# CONFIG_IPX is not set
+# CONFIG_ATALK is not set
+# CONFIG_X25 is not set
+# CONFIG_LAPB is not set
+# CONFIG_PHONET is not set
+# CONFIG_IEEE802154 is not set
+# CONFIG_NET_SCHED is not set
+# CONFIG_DCB is not set
+# CONFIG_BATMAN_ADV is not set
+# CONFIG_OPENVSWITCH is not set
+# CONFIG_VSOCKETS is not set
+# CONFIG_NETLINK_MMAP is not set
+# CONFIG_NETLINK_DIAG is not set
+# CONFIG_NET_MPLS_GSO is not set
+# CONFIG_HSR is not set
+CONFIG_RPS=y
+CONFIG_RFS_ACCEL=y
+CONFIG_XPS=y
+CONFIG_NET_RX_BUSY_POLL=y
+CONFIG_BQL=y
+CONFIG_NET_FLOW_LIMIT=y
+
+#
+# Network testing
+#
+# CONFIG_NET_PKTGEN is not set
+# CONFIG_HAMRADIO is not set
+# CONFIG_CAN is not set
+# CONFIG_IRDA is not set
+# CONFIG_BT is not set
+# CONFIG_AF_RXRPC is not set
+# CONFIG_WIRELESS is not set
+# CONFIG_WIMAX is not set
+# CONFIG_RFKILL is not set
+# CONFIG_NET_9P is not set
+# CONFIG_CAIF is not set
+# CONFIG_CEPH_LIB is not set
+# CONFIG_NFC is not set
+CONFIG_HAVE_BPF_JIT=y
+
+#
+# Device Drivers
+#
+
+#
+# Generic Driver Options
+#
+CONFIG_UEVENT_HELPER=y
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_STANDALONE=y
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+CONFIG_FW_LOADER=y
+# CONFIG_FIRMWARE_IN_KERNEL is not set
+CONFIG_EXTRA_FIRMWARE=""
+# CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set
+# CONFIG_DEBUG_DRIVER is not set
+# CONFIG_DEBUG_DEVRES is not set
+CONFIG_SYS_HYPERVISOR=y
+# CONFIG_GENERIC_CPU_DEVICES is not set
+CONFIG_GENERIC_CPU_AUTOPROBE=y
+# CONFIG_DMA_SHARED_BUFFER is not set
+
+#
+# Bus devices
+#
+# CONFIG_CONNECTOR is not set
+# CONFIG_MTD is not set
+CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
+# CONFIG_PARPORT is not set
+CONFIG_BLK_DEV=y
+# CONFIG_BLK_DEV_NULL_BLK is not set
+# CONFIG_BLK_DEV_FD is not set
+# CONFIG_BLK_DEV_COW_COMMON is not set
+# CONFIG_BLK_DEV_LOOP is not set
+# CONFIG_BLK_DEV_DRBD is not set
+# CONFIG_BLK_DEV_NBD is not set
+# CONFIG_BLK_DEV_RAM is not set
+# CONFIG_CDROM_PKTCDVD is not set
+# CONFIG_ATA_OVER_ETH is not set
+CONFIG_XEN_BLKDEV_FRONTEND=y
+# CONFIG_BLK_DEV_HD is not set
+# CONFIG_BLK_DEV_RBD is not set
+
+#
+# Misc devices
+#
+# CONFIG_SENSORS_LIS3LV02D is not set
+# CONFIG_DUMMY_IRQ is not set
+# CONFIG_ENCLOSURE_SERVICES is not set
+# CONFIG_VMWARE_BALLOON is not set
+# CONFIG_SRAM is not set
+# CONFIG_C2PORT is not set
+
+#
+# EEPROM support
+#
+# CONFIG_EEPROM_93CX6 is not set
+
+#
+# Texas Instruments shared transport line discipline
+#
+
+#
+# Altera FPGA firmware download module
+#
+
+#
+# Intel MIC Bus Driver
+#
+
+#
+# Intel MIC Host Driver
+#
+
+#
+# Intel MIC Card Driver
+#
+# CONFIG_ECHO is not set
+CONFIG_HAVE_IDE=y
+# CONFIG_IDE is not set
+
+#
+# SCSI device support
+#
+CONFIG_SCSI_MOD=y
+# CONFIG_RAID_ATTRS is not set
+# CONFIG_SCSI is not set
+# CONFIG_SCSI_DMA is not set
+# CONFIG_SCSI_NETLINK is not set
+# CONFIG_ATA is not set
+# CONFIG_MD is not set
+# CONFIG_MACINTOSH_DRIVERS is not set
+CONFIG_NETDEVICES=y
+CONFIG_NET_CORE=y
+# CONFIG_BONDING is not set
+# CONFIG_DUMMY is not set
+# CONFIG_EQUALIZER is not set
+# CONFIG_NET_TEAM is not set
+# CONFIG_MACVLAN is not set
+# CONFIG_VXLAN is not set
+# CONFIG_NETCONSOLE is not set
+# CONFIG_NETPOLL is not set
+# CONFIG_NET_POLL_CONTROLLER is not set
+CONFIG_TUN=y
+# CONFIG_VETH is not set
+# CONFIG_NLMON is not set
+
+#
+# CAIF transport drivers
+#
+# CONFIG_VHOST_NET is not set
+
+#
+# Distributed Switch Architecture drivers
+#
+# CONFIG_NET_DSA_MV88E6XXX is not set
+# CONFIG_NET_DSA_MV88E6060 is not set
+# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
+# CONFIG_NET_DSA_MV88E6131 is not set
+# CONFIG_NET_DSA_MV88E6123_61_65 is not set
+# CONFIG_ETHERNET is not set
+# CONFIG_PHYLIB is not set
+# CONFIG_PPP is not set
+# CONFIG_SLIP is not set
+
+#
+# Host-side USB support is needed for USB Network Adapter support
+#
+# CONFIG_WLAN is not set
+
+#
+# Enable WiMAX (Networking options) to see the WiMAX drivers
+#
+# CONFIG_WAN is not set
+CONFIG_XEN_NETDEV_FRONTEND=y
+# CONFIG_ISDN is not set
+
+#
+# Input device support
+#
+CONFIG_INPUT=y
+# CONFIG_INPUT_FF_MEMLESS is not set
+# CONFIG_INPUT_POLLDEV is not set
+# CONFIG_INPUT_SPARSEKMAP is not set
+# CONFIG_INPUT_MATRIXKMAP is not set
+
+#
+# Userland interfaces
+#
+CONFIG_INPUT_MOUSEDEV=y
+# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
+CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
+CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
+# CONFIG_INPUT_JOYDEV is not set
+# CONFIG_INPUT_EVDEV is not set
+# CONFIG_INPUT_EVBUG is not set
+
+#
+# Input Device Drivers
+#
+CONFIG_INPUT_KEYBOARD=y
+CONFIG_KEYBOARD_ATKBD=y
+# CONFIG_KEYBOARD_LKKBD is not set
+# CONFIG_KEYBOARD_NEWTON is not set
+# CONFIG_KEYBOARD_OPENCORES is not set
+# CONFIG_KEYBOARD_STOWAWAY is not set
+# CONFIG_KEYBOARD_SUNKBD is not set
+# CONFIG_KEYBOARD_XTKBD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_INPUT_JOYSTICK is not set
+# CONFIG_INPUT_TABLET is not set
+# CONFIG_INPUT_TOUCHSCREEN is not set
+CONFIG_INPUT_MISC=y
+# CONFIG_INPUT_AD714X is not set
+# CONFIG_INPUT_PCSPKR is not set
+# CONFIG_INPUT_UINPUT is not set
+# CONFIG_INPUT_ADXL34X is not set
+# CONFIG_INPUT_CMA3000 is not set
+CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
+# CONFIG_INPUT_IDEAPAD_SLIDEBAR is not set
+
+#
+# Hardware I/O ports
+#
+CONFIG_SERIO=y
+CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y
+CONFIG_SERIO_I8042=y
+# CONFIG_SERIO_SERPORT is not set
+# CONFIG_SERIO_CT82C710 is not set
+CONFIG_SERIO_LIBPS2=y
+# CONFIG_SERIO_RAW is not set
+# CONFIG_SERIO_ALTERA_PS2 is not set
+# CONFIG_SERIO_PS2MULT is not set
+# CONFIG_SERIO_ARC_PS2 is not set
+# CONFIG_GAMEPORT is not set
+
+#
+# Character devices
+#
+CONFIG_TTY=y
+CONFIG_VT=y
+CONFIG_CONSOLE_TRANSLATIONS=y
+CONFIG_VT_CONSOLE=y
+CONFIG_VT_CONSOLE_SLEEP=y
+CONFIG_HW_CONSOLE=y
+CONFIG_VT_HW_CONSOLE_BINDING=y
+CONFIG_UNIX98_PTYS=y
+# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
+# CONFIG_LEGACY_PTYS is not set
+# CONFIG_SERIAL_NONSTANDARD is not set
+# CONFIG_N_GSM is not set
+# CONFIG_TRACE_SINK is not set
+# CONFIG_DEVKMEM is not set
+
+#
+# Serial drivers
+#
+# CONFIG_SERIAL_8250 is not set
+
+#
+# Non-8250 serial port support
+#
+# CONFIG_SERIAL_SCCNXP is not set
+# CONFIG_SERIAL_ALTERA_JTAGUART is not set
+# CONFIG_SERIAL_ALTERA_UART is not set
+# CONFIG_SERIAL_ARC is not set
+# CONFIG_SERIAL_FSL_LPUART is not set
+# CONFIG_TTY_PRINTK is not set
+CONFIG_HVC_DRIVER=y
+CONFIG_HVC_IRQ=y
+CONFIG_HVC_XEN=y
+CONFIG_HVC_XEN_FRONTEND=y
+# CONFIG_IPMI_HANDLER is not set
+# CONFIG_HW_RANDOM is not set
+# CONFIG_NVRAM is not set
+# CONFIG_R3964 is not set
+# CONFIG_MWAVE is not set
+# CONFIG_RAW_DRIVER is not set
+# CONFIG_HANGCHECK_TIMER is not set
+# CONFIG_TCG_TPM is not set
+# CONFIG_TELCLOCK is not set
+
+#
+# I2C support
+#
+# CONFIG_I2C is not set
+# CONFIG_SPI is not set
+# CONFIG_SPMI is not set
+# CONFIG_HSI is not set
+
+#
+# PPS support
+#
+# CONFIG_PPS is not set
+
+#
+# PPS generators support
+#
+
+#
+# PTP clock support
+#
+# CONFIG_PTP_1588_CLOCK is not set
+
+#
+# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
+#
+CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
+# CONFIG_GPIOLIB is not set
+# CONFIG_W1 is not set
+# CONFIG_POWER_SUPPLY is not set
+# CONFIG_POWER_AVS is not set
+# CONFIG_HWMON is not set
+# CONFIG_THERMAL is not set
+# CONFIG_WATCHDOG is not set
+CONFIG_SSB_POSSIBLE=y
+
+#
+# Sonics Silicon Backplane
+#
+# CONFIG_SSB is not set
+CONFIG_BCMA_POSSIBLE=y
+
+#
+# Broadcom specific AMBA
+#
+# CONFIG_BCMA is not set
+
+#
+# Multifunction device drivers
+#
+# CONFIG_MFD_CORE is not set
+# CONFIG_MFD_CROS_EC is not set
+# CONFIG_HTC_PASIC3 is not set
+# CONFIG_MFD_KEMPLD is not set
+# CONFIG_MFD_SM501 is not set
+# CONFIG_ABX500_CORE is not set
+# CONFIG_MFD_SYSCON is not set
+# CONFIG_MFD_TI_AM335X_TSCADC is not set
+# CONFIG_MFD_TMIO is not set
+# CONFIG_REGULATOR is not set
+# CONFIG_MEDIA_SUPPORT is not set
+
+#
+# Graphics support
+#
+
+#
+# Direct Rendering Manager
+#
+# CONFIG_DRM is not set
+
+#
+# Frame buffer Devices
+#
+CONFIG_FB=y
+# CONFIG_FIRMWARE_EDID is not set
+# CONFIG_FB_DDC is not set
+# CONFIG_FB_BOOT_VESA_SUPPORT is not set
+# CONFIG_FB_CFB_FILLRECT is not set
+# CONFIG_FB_CFB_COPYAREA is not set
+# CONFIG_FB_CFB_IMAGEBLIT is not set
+# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
+CONFIG_FB_SYS_FILLRECT=y
+CONFIG_FB_SYS_COPYAREA=y
+CONFIG_FB_SYS_IMAGEBLIT=y
+# CONFIG_FB_FOREIGN_ENDIAN is not set
+CONFIG_FB_SYS_FOPS=y
+CONFIG_FB_DEFERRED_IO=y
+# CONFIG_FB_SVGALIB is not set
+# CONFIG_FB_MACMODES is not set
+# CONFIG_FB_BACKLIGHT is not set
+# CONFIG_FB_MODE_HELPERS is not set
+# CONFIG_FB_TILEBLITTING is not set
+
+#
+# Frame buffer hardware drivers
+#
+# CONFIG_FB_ARC is not set
+# CONFIG_FB_VGA16 is not set
+# CONFIG_FB_VESA is not set
+# CONFIG_FB_N411 is not set
+# CONFIG_FB_HGA is not set
+# CONFIG_FB_OPENCORES is not set
+# CONFIG_FB_S1D13XXX is not set
+# CONFIG_FB_VIRTUAL is not set
+CONFIG_XEN_FBDEV_FRONTEND=y
+# CONFIG_FB_METRONOME is not set
+# CONFIG_FB_BROADSHEET is not set
+# CONFIG_FB_AUO_K190X is not set
+# CONFIG_FB_SIMPLE is not set
+# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
+# CONFIG_VGASTATE is not set
+
+#
+# Console display driver support
+#
+# CONFIG_VGA_CONSOLE is not set
+CONFIG_DUMMY_CONSOLE=y
+# CONFIG_FRAMEBUFFER_CONSOLE is not set
+# CONFIG_LOGO is not set
+# CONFIG_SOUND is not set
+
+#
+# HID support
+#
+# CONFIG_HID is not set
+CONFIG_USB_OHCI_LITTLE_ENDIAN=y
+# CONFIG_USB_SUPPORT is not set
+# CONFIG_MMC is not set
+# CONFIG_MEMSTICK is not set
+# CONFIG_NEW_LEDS is not set
+# CONFIG_ACCESSIBILITY is not set
+# CONFIG_EDAC is not set
+CONFIG_RTC_LIB=y
+# CONFIG_RTC_CLASS is not set
+# CONFIG_DMADEVICES is not set
+# CONFIG_AUXDISPLAY is not set
+# CONFIG_UIO is not set
+# CONFIG_VIRT_DRIVERS is not set
+
+#
+# Virtio drivers
+#
+# CONFIG_VIRTIO_MMIO is not set
+
+#
+# Microsoft Hyper-V guest support
+#
+
+#
+# Xen driver support
+#
+# CONFIG_XEN_BALLOON is not set
+CONFIG_XEN_DEV_EVTCHN=y
+CONFIG_XENFS=y
+CONFIG_XEN_COMPAT_XENFS=y
+CONFIG_XEN_SYS_HYPERVISOR=y
+CONFIG_XEN_XENBUS_FRONTEND=y
+CONFIG_XEN_GNTDEV=y
+CONFIG_XEN_GRANT_DEV_ALLOC=y
+CONFIG_SWIOTLB_XEN=y
+CONFIG_XEN_PRIVCMD=y
+CONFIG_XEN_HAVE_PVMMU=y
+# CONFIG_STAGING is not set
+# CONFIG_X86_PLATFORM_DEVICES is not set
+# CONFIG_CHROME_PLATFORMS is not set
+
+#
+# SOC (System On Chip) specific Drivers
+#
+
+#
+# Hardware Spinlock drivers
+#
+
+#
+# Clock Source drivers
+#
+CONFIG_CLKEVT_I8253=y
+CONFIG_I8253_LOCK=y
+CONFIG_CLKBLD_I8253=y
+# CONFIG_SH_TIMER_CMT is not set
+# CONFIG_SH_TIMER_MTU2 is not set
+# CONFIG_SH_TIMER_TMU is not set
+# CONFIG_EM_TIMER_STI is not set
+# CONFIG_MAILBOX is not set
+# CONFIG_IOMMU_SUPPORT is not set
+
+#
+# Remoteproc drivers
+#
+# CONFIG_STE_MODEM_RPROC is not set
+
+#
+# Rpmsg drivers
+#
+# CONFIG_PM_DEVFREQ is not set
+# CONFIG_EXTCON is not set
+# CONFIG_MEMORY is not set
+# CONFIG_IIO is not set
+# CONFIG_PWM is not set
+# CONFIG_IPACK_BUS is not set
+# CONFIG_RESET_CONTROLLER is not set
+# CONFIG_FMC is not set
+
+#
+# PHY Subsystem
+#
+# CONFIG_GENERIC_PHY is not set
+# CONFIG_BCM_KONA_USB2_PHY is not set
+# CONFIG_POWERCAP is not set
+# CONFIG_MCB is not set
+
+#
+# Firmware Drivers
+#
+# CONFIG_EDD is not set
+CONFIG_FIRMWARE_MEMMAP=y
+# CONFIG_DELL_RBU is not set
+# CONFIG_DCDBAS is not set
+# CONFIG_DMIID is not set
+# CONFIG_DMI_SYSFS is not set
+CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y
+# CONFIG_GOOGLE_FIRMWARE is not set
+
+#
+# File systems
+#
+CONFIG_DCACHE_WORD_ACCESS=y
+CONFIG_EXT2_FS=y
+# CONFIG_EXT2_FS_XATTR is not set
+# CONFIG_EXT2_FS_XIP is not set
+# CONFIG_EXT3_FS is not set
+# CONFIG_EXT4_FS is not set
+# CONFIG_REISERFS_FS is not set
+# CONFIG_JFS_FS is not set
+# CONFIG_XFS_FS is not set
+# CONFIG_GFS2_FS is not set
+# CONFIG_BTRFS_FS is not set
+# CONFIG_NILFS2_FS is not set
+# CONFIG_FS_POSIX_ACL is not set
+CONFIG_FILE_LOCKING=y
+CONFIG_FSNOTIFY=y
+# CONFIG_DNOTIFY is not set
+CONFIG_INOTIFY_USER=y
+# CONFIG_FANOTIFY is not set
+# CONFIG_QUOTA is not set
+# CONFIG_QUOTACTL is not set
+CONFIG_AUTOFS4_FS=y
+# CONFIG_FUSE_FS is not set
+
+#
+# Caches
+#
+# CONFIG_FSCACHE is not set
+
+#
+# CD-ROM/DVD Filesystems
+#
+# CONFIG_ISO9660_FS is not set
+# CONFIG_UDF_FS is not set
+
+#
+# DOS/FAT/NT Filesystems
+#
+# CONFIG_MSDOS_FS is not set
+# CONFIG_VFAT_FS is not set
+# CONFIG_NTFS_FS is not set
+
+#
+# Pseudo filesystems
+#
+CONFIG_PROC_FS=y
+# CONFIG_PROC_KCORE is not set
+# CONFIG_PROC_SYSCTL is not set
+# CONFIG_PROC_PAGE_MONITOR is not set
+CONFIG_KERNFS=y
+CONFIG_SYSFS=y
+# CONFIG_TMPFS is not set
+# CONFIG_HUGETLBFS is not set
+# CONFIG_HUGETLB_PAGE is not set
+# CONFIG_CONFIGFS_FS is not set
+CONFIG_MISC_FILESYSTEMS=y
+# CONFIG_ADFS_FS is not set
+# CONFIG_AFFS_FS is not set
+# CONFIG_HFS_FS is not set
+# CONFIG_HFSPLUS_FS is not set
+# CONFIG_BEFS_FS is not set
+# CONFIG_BFS_FS is not set
+# CONFIG_EFS_FS is not set
+# CONFIG_LOGFS is not set
+CONFIG_CRAMFS=y
+CONFIG_SQUASHFS=y
+CONFIG_SQUASHFS_FILE_CACHE=y
+# CONFIG_SQUASHFS_FILE_DIRECT is not set
+CONFIG_SQUASHFS_DECOMP_SINGLE=y
+# CONFIG_SQUASHFS_DECOMP_MULTI is not set
+# CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU is not set
+# CONFIG_SQUASHFS_XATTR is not set
+CONFIG_SQUASHFS_ZLIB=y
+# CONFIG_SQUASHFS_LZO is not set
+# CONFIG_SQUASHFS_XZ is not set
+# CONFIG_SQUASHFS_4K_DEVBLK_SIZE is not set
+# CONFIG_SQUASHFS_EMBEDDED is not set
+CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3
+# CONFIG_VXFS_FS is not set
+# CONFIG_MINIX_FS is not set
+# CONFIG_OMFS_FS is not set
+# CONFIG_HPFS_FS is not set
+# CONFIG_QNX4FS_FS is not set
+# CONFIG_QNX6FS_FS is not set
+CONFIG_ROMFS_FS=y
+CONFIG_ROMFS_BACKED_BY_BLOCK=y
+CONFIG_ROMFS_ON_BLOCK=y
+# CONFIG_PSTORE is not set
+# CONFIG_SYSV_FS is not set
+# CONFIG_UFS_FS is not set
+# CONFIG_F2FS_FS is not set
+# CONFIG_NETWORK_FILESYSTEMS is not set
+CONFIG_NLS=y
+CONFIG_NLS_DEFAULT="iso8859-1"
+# CONFIG_NLS_CODEPAGE_437 is not set
+# CONFIG_NLS_CODEPAGE_737 is not set
+# CONFIG_NLS_CODEPAGE_775 is not set
+# CONFIG_NLS_CODEPAGE_850 is not set
+# CONFIG_NLS_CODEPAGE_852 is not set
+# CONFIG_NLS_CODEPAGE_855 is not set
+# CONFIG_NLS_CODEPAGE_857 is not set
+# CONFIG_NLS_CODEPAGE_860 is not set
+# CONFIG_NLS_CODEPAGE_861 is not set
+# CONFIG_NLS_CODEPAGE_862 is not set
+# CONFIG_NLS_CODEPAGE_863 is not set
+# CONFIG_NLS_CODEPAGE_864 is not set
+# CONFIG_NLS_CODEPAGE_865 is not set
+# CONFIG_NLS_CODEPAGE_866 is not set
+# CONFIG_NLS_CODEPAGE_869 is not set
+# CONFIG_NLS_CODEPAGE_936 is not set
+# CONFIG_NLS_CODEPAGE_950 is not set
+# CONFIG_NLS_CODEPAGE_932 is not set
+# CONFIG_NLS_CODEPAGE_949 is not set
+# CONFIG_NLS_CODEPAGE_874 is not set
+# CONFIG_NLS_ISO8859_8 is not set
+# CONFIG_NLS_CODEPAGE_1250 is not set
+# CONFIG_NLS_CODEPAGE_1251 is not set
+# CONFIG_NLS_ASCII is not set
+# CONFIG_NLS_ISO8859_1 is not set
+# CONFIG_NLS_ISO8859_2 is not set
+# CONFIG_NLS_ISO8859_3 is not set
+# CONFIG_NLS_ISO8859_4 is not set
+# CONFIG_NLS_ISO8859_5 is not set
+# CONFIG_NLS_ISO8859_6 is not set
+# CONFIG_NLS_ISO8859_7 is not set
+# CONFIG_NLS_ISO8859_9 is not set
+# CONFIG_NLS_ISO8859_13 is not set
+# CONFIG_NLS_ISO8859_14 is not set
+# CONFIG_NLS_ISO8859_15 is not set
+# CONFIG_NLS_KOI8_R is not set
+# CONFIG_NLS_KOI8_U is not set
+# CONFIG_NLS_MAC_ROMAN is not set
+# CONFIG_NLS_MAC_CELTIC is not set
+# CONFIG_NLS_MAC_CENTEURO is not set
+# CONFIG_NLS_MAC_CROATIAN is not set
+# CONFIG_NLS_MAC_CYRILLIC is not set
+# CONFIG_NLS_MAC_GAELIC is not set
+# CONFIG_NLS_MAC_GREEK is not set
+# CONFIG_NLS_MAC_ICELAND is not set
+# CONFIG_NLS_MAC_INUIT is not set
+# CONFIG_NLS_MAC_ROMANIAN is not set
+# CONFIG_NLS_MAC_TURKISH is not set
+# CONFIG_NLS_UTF8 is not set
+
+#
+# Kernel hacking
+#
+CONFIG_TRACE_IRQFLAGS_SUPPORT=y
+
+#
+# printk and dmesg options
+#
+# CONFIG_PRINTK_TIME is not set
+CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4
+# CONFIG_BOOT_PRINTK_DELAY is not set
+
+#
+# Compile-time checks and compiler options
+#
+# CONFIG_DEBUG_INFO is not set
+# CONFIG_ENABLE_WARN_DEPRECATED is not set
+# CONFIG_ENABLE_MUST_CHECK is not set
+CONFIG_FRAME_WARN=1024
+# CONFIG_STRIP_ASM_SYMS is not set
+# CONFIG_READABLE_ASM is not set
+# CONFIG_UNUSED_SYMBOLS is not set
+# CONFIG_DEBUG_FS is not set
+# CONFIG_HEADERS_CHECK is not set
+# CONFIG_DEBUG_SECTION_MISMATCH is not set
+CONFIG_ARCH_WANT_FRAME_POINTERS=y
+# CONFIG_FRAME_POINTER is not set
+# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
+# CONFIG_MAGIC_SYSRQ is not set
+CONFIG_DEBUG_KERNEL=y
+
+#
+# Memory Debugging
+#
+# CONFIG_DEBUG_PAGEALLOC is not set
+# CONFIG_DEBUG_OBJECTS is not set
+# CONFIG_SLUB_DEBUG_ON is not set
+# CONFIG_SLUB_STATS is not set
+CONFIG_HAVE_DEBUG_KMEMLEAK=y
+# CONFIG_DEBUG_KMEMLEAK is not set
+# CONFIG_DEBUG_STACK_USAGE is not set
+# CONFIG_DEBUG_VM is not set
+# CONFIG_DEBUG_VIRTUAL is not set
+CONFIG_DEBUG_MEMORY_INIT=y
+# CONFIG_DEBUG_PER_CPU_MAPS is not set
+CONFIG_HAVE_DEBUG_STACKOVERFLOW=y
+# CONFIG_DEBUG_STACKOVERFLOW is not set
+CONFIG_HAVE_ARCH_KMEMCHECK=y
+# CONFIG_KMEMCHECK is not set
+# CONFIG_DEBUG_SHIRQ is not set
+
+#
+# Debug Lockups and Hangs
+#
+# CONFIG_LOCKUP_DETECTOR is not set
+# CONFIG_DETECT_HUNG_TASK is not set
+# CONFIG_PANIC_ON_OOPS is not set
+CONFIG_PANIC_ON_OOPS_VALUE=0
+CONFIG_PANIC_TIMEOUT=0
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_SCHEDSTATS is not set
+# CONFIG_TIMER_STATS is not set
+
+#
+# Lock Debugging (spinlocks, mutexes, etc...)
+#
+# CONFIG_DEBUG_RT_MUTEXES is not set
+# CONFIG_DEBUG_SPINLOCK is not set
+# CONFIG_DEBUG_MUTEXES is not set
+# CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set
+# CONFIG_DEBUG_LOCK_ALLOC is not set
+# CONFIG_PROVE_LOCKING is not set
+# CONFIG_LOCK_STAT is not set
+# CONFIG_DEBUG_ATOMIC_SLEEP is not set
+# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
+# CONFIG_LOCK_TORTURE_TEST is not set
+# CONFIG_STACKTRACE is not set
+# CONFIG_DEBUG_KOBJECT is not set
+CONFIG_DEBUG_BUGVERBOSE=y
+# CONFIG_DEBUG_LIST is not set
+# CONFIG_DEBUG_PI_LIST is not set
+# CONFIG_DEBUG_SG is not set
+# CONFIG_DEBUG_NOTIFIERS is not set
+# CONFIG_DEBUG_CREDENTIALS is not set
+
+#
+# RCU Debugging
+#
+# CONFIG_SPARSE_RCU_POINTER is not set
+# CONFIG_TORTURE_TEST is not set
+# CONFIG_RCU_TORTURE_TEST is not set
+CONFIG_RCU_CPU_STALL_TIMEOUT=21
+# CONFIG_RCU_CPU_STALL_INFO is not set
+# CONFIG_RCU_TRACE is not set
+# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
+# CONFIG_NOTIFIER_ERROR_INJECTION is not set
+# CONFIG_FAULT_INJECTION is not set
+# CONFIG_LATENCYTOP is not set
+CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS=y
+# CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set
+CONFIG_USER_STACKTRACE_SUPPORT=y
+CONFIG_HAVE_FUNCTION_TRACER=y
+CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
+CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
+CONFIG_HAVE_DYNAMIC_FTRACE=y
+CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y
+CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
+CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
+CONFIG_HAVE_FENTRY=y
+CONFIG_HAVE_C_RECORDMCOUNT=y
+CONFIG_TRACING_SUPPORT=y
+# CONFIG_FTRACE is not set
+
+#
+# Runtime Testing
+#
+# CONFIG_TEST_LIST_SORT is not set
+# CONFIG_BACKTRACE_SELF_TEST is not set
+# CONFIG_RBTREE_TEST is not set
+# CONFIG_ATOMIC64_SELFTEST is not set
+# CONFIG_TEST_STRING_HELPERS is not set
+# CONFIG_TEST_KSTRTOX is not set
+# CONFIG_TEST_RHASHTABLE is not set
+# CONFIG_DMA_API_DEBUG is not set
+# CONFIG_TEST_FIRMWARE is not set
+# CONFIG_TEST_UDELAY is not set
+# CONFIG_SAMPLES is not set
+CONFIG_HAVE_ARCH_KGDB=y
+# CONFIG_KGDB is not set
+# CONFIG_STRICT_DEVMEM is not set
+# CONFIG_X86_VERBOSE_BOOTUP is not set
+CONFIG_EARLY_PRINTK=y
+# CONFIG_X86_PTDUMP is not set
+CONFIG_DEBUG_RODATA=y
+CONFIG_DEBUG_RODATA_TEST=y
+CONFIG_DOUBLEFAULT=y
+# CONFIG_DEBUG_TLBFLUSH is not set
+# CONFIG_IOMMU_STRESS is not set
+CONFIG_HAVE_MMIOTRACE_SUPPORT=y
+CONFIG_IO_DELAY_TYPE_0X80=0
+CONFIG_IO_DELAY_TYPE_0XED=1
+CONFIG_IO_DELAY_TYPE_UDELAY=2
+CONFIG_IO_DELAY_TYPE_NONE=3
+CONFIG_IO_DELAY_0X80=y
+# CONFIG_IO_DELAY_0XED is not set
+# CONFIG_IO_DELAY_UDELAY is not set
+# CONFIG_IO_DELAY_NONE is not set
+CONFIG_DEFAULT_IO_DELAY_TYPE=0
+# CONFIG_CPA_DEBUG is not set
+# CONFIG_OPTIMIZE_INLINING is not set
+# CONFIG_DEBUG_NMI_SELFTEST is not set
+# CONFIG_X86_DEBUG_STATIC_CPU_HAS is not set
+
+#
+# Security options
+#
+# CONFIG_KEYS is not set
+# CONFIG_SECURITY_DMESG_RESTRICT is not set
+# CONFIG_SECURITY is not set
+# CONFIG_SECURITYFS is not set
+CONFIG_DEFAULT_SECURITY_DAC=y
+CONFIG_DEFAULT_SECURITY=""
+CONFIG_CRYPTO=y
+
+#
+# Crypto core or helper
+#
+CONFIG_CRYPTO_ALGAPI=y
+CONFIG_CRYPTO_ALGAPI2=y
+CONFIG_CRYPTO_AEAD2=y
+CONFIG_CRYPTO_BLKCIPHER=y
+CONFIG_CRYPTO_BLKCIPHER2=y
+CONFIG_CRYPTO_HASH2=y
+CONFIG_CRYPTO_RNG2=y
+CONFIG_CRYPTO_PCOMP2=y
+CONFIG_CRYPTO_MANAGER=y
+CONFIG_CRYPTO_MANAGER2=y
+# CONFIG_CRYPTO_USER is not set
+# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
+# CONFIG_CRYPTO_GF128MUL is not set
+# CONFIG_CRYPTO_NULL is not set
+# CONFIG_CRYPTO_PCRYPT is not set
+CONFIG_CRYPTO_WORKQUEUE=y
+# CONFIG_CRYPTO_CRYPTD is not set
+# CONFIG_CRYPTO_AUTHENC is not set
+
+#
+# Authenticated Encryption with Associated Data
+#
+# CONFIG_CRYPTO_CCM is not set
+# CONFIG_CRYPTO_GCM is not set
+# CONFIG_CRYPTO_SEQIV is not set
+
+#
+# Block modes
+#
+CONFIG_CRYPTO_CBC=y
+# CONFIG_CRYPTO_CTR is not set
+# CONFIG_CRYPTO_CTS is not set
+# CONFIG_CRYPTO_ECB is not set
+# CONFIG_CRYPTO_LRW is not set
+# CONFIG_CRYPTO_PCBC is not set
+# CONFIG_CRYPTO_XTS is not set
+
+#
+# Hash modes
+#
+# CONFIG_CRYPTO_CMAC is not set
+# CONFIG_CRYPTO_HMAC is not set
+# CONFIG_CRYPTO_XCBC is not set
+# CONFIG_CRYPTO_VMAC is not set
+
+#
+# Digest
+#
+# CONFIG_CRYPTO_CRC32C is not set
+# CONFIG_CRYPTO_CRC32C_INTEL is not set
+# CONFIG_CRYPTO_CRC32 is not set
+# CONFIG_CRYPTO_CRC32_PCLMUL is not set
+# CONFIG_CRYPTO_CRCT10DIF is not set
+# CONFIG_CRYPTO_GHASH is not set
+# CONFIG_CRYPTO_MD4 is not set
+# CONFIG_CRYPTO_MD5 is not set
+# CONFIG_CRYPTO_MICHAEL_MIC is not set
+# CONFIG_CRYPTO_RMD128 is not set
+# CONFIG_CRYPTO_RMD160 is not set
+# CONFIG_CRYPTO_RMD256 is not set
+# CONFIG_CRYPTO_RMD320 is not set
+# CONFIG_CRYPTO_SHA1 is not set
+# CONFIG_CRYPTO_SHA1_SSSE3 is not set
+# CONFIG_CRYPTO_SHA256_SSSE3 is not set
+# CONFIG_CRYPTO_SHA512_SSSE3 is not set
+# CONFIG_CRYPTO_SHA256 is not set
+# CONFIG_CRYPTO_SHA512 is not set
+# CONFIG_CRYPTO_TGR192 is not set
+# CONFIG_CRYPTO_WP512 is not set
+# CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL is not set
+
+#
+# Ciphers
+#
+CONFIG_CRYPTO_AES=y
+# CONFIG_CRYPTO_AES_X86_64 is not set
+# CONFIG_CRYPTO_AES_NI_INTEL is not set
+# CONFIG_CRYPTO_ANUBIS is not set
+# CONFIG_CRYPTO_ARC4 is not set
+# CONFIG_CRYPTO_BLOWFISH is not set
+# CONFIG_CRYPTO_BLOWFISH_X86_64 is not set
+# CONFIG_CRYPTO_CAMELLIA is not set
+# CONFIG_CRYPTO_CAMELLIA_X86_64 is not set
+# CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64 is not set
+# CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64 is not set
+# CONFIG_CRYPTO_CAST5 is not set
+# CONFIG_CRYPTO_CAST5_AVX_X86_64 is not set
+# CONFIG_CRYPTO_CAST6 is not set
+# CONFIG_CRYPTO_CAST6_AVX_X86_64 is not set
+# CONFIG_CRYPTO_DES is not set
+# CONFIG_CRYPTO_DES3_EDE_X86_64 is not set
+# CONFIG_CRYPTO_FCRYPT is not set
+# CONFIG_CRYPTO_KHAZAD is not set
+# CONFIG_CRYPTO_SALSA20 is not set
+# CONFIG_CRYPTO_SALSA20_X86_64 is not set
+# CONFIG_CRYPTO_SEED is not set
+# CONFIG_CRYPTO_SERPENT is not set
+# CONFIG_CRYPTO_SERPENT_SSE2_X86_64 is not set
+# CONFIG_CRYPTO_SERPENT_AVX_X86_64 is not set
+# CONFIG_CRYPTO_SERPENT_AVX2_X86_64 is not set
+# CONFIG_CRYPTO_TEA is not set
+# CONFIG_CRYPTO_TWOFISH is not set
+# CONFIG_CRYPTO_TWOFISH_X86_64 is not set
+# CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set
+# CONFIG_CRYPTO_TWOFISH_AVX_X86_64 is not set
+
+#
+# Compression
+#
+# CONFIG_CRYPTO_DEFLATE is not set
+# CONFIG_CRYPTO_ZLIB is not set
+# CONFIG_CRYPTO_LZO is not set
+# CONFIG_CRYPTO_LZ4 is not set
+# CONFIG_CRYPTO_LZ4HC is not set
+
+#
+# Random Number Generation
+#
+# CONFIG_CRYPTO_ANSI_CPRNG is not set
+# CONFIG_CRYPTO_DRBG_MENU is not set
+# CONFIG_CRYPTO_USER_API_HASH is not set
+# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
+# CONFIG_CRYPTO_HW is not set
+CONFIG_HAVE_KVM=y
+CONFIG_VIRTUALIZATION=y
+# CONFIG_BINARY_PRINTF is not set
+
+#
+# Library routines
+#
+CONFIG_BITREVERSE=y
+CONFIG_GENERIC_STRNCPY_FROM_USER=y
+CONFIG_GENERIC_STRNLEN_USER=y
+CONFIG_GENERIC_NET_UTILS=y
+CONFIG_GENERIC_FIND_FIRST_BIT=y
+CONFIG_GENERIC_PCI_IOMAP=y
+CONFIG_GENERIC_IOMAP=y
+CONFIG_GENERIC_IO=y
+CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
+CONFIG_ARCH_HAS_FAST_MULTIPLIER=y
+# CONFIG_CRC_CCITT is not set
+# CONFIG_CRC16 is not set
+# CONFIG_CRC_T10DIF is not set
+# CONFIG_CRC_ITU_T is not set
+CONFIG_CRC32=y
+# CONFIG_CRC32_SELFTEST is not set
+CONFIG_CRC32_SLICEBY8=y
+# CONFIG_CRC32_SLICEBY4 is not set
+# CONFIG_CRC32_SARWATE is not set
+# CONFIG_CRC32_BIT is not set
+# CONFIG_CRC7 is not set
+# CONFIG_LIBCRC32C is not set
+# CONFIG_CRC8 is not set
+# CONFIG_AUDIT_ARCH_COMPAT_GENERIC is not set
+# CONFIG_RANDOM32_SELFTEST is not set
+CONFIG_ZLIB_INFLATE=y
+CONFIG_LZO_DECOMPRESS=y
+CONFIG_LZ4_DECOMPRESS=y
+CONFIG_XZ_DEC=y
+CONFIG_XZ_DEC_X86=y
+CONFIG_XZ_DEC_POWERPC=y
+CONFIG_XZ_DEC_IA64=y
+CONFIG_XZ_DEC_ARM=y
+CONFIG_XZ_DEC_ARMTHUMB=y
+CONFIG_XZ_DEC_SPARC=y
+CONFIG_XZ_DEC_BCJ=y
+# CONFIG_XZ_DEC_TEST is not set
+CONFIG_DECOMPRESS_GZIP=y
+CONFIG_DECOMPRESS_BZIP2=y
+CONFIG_DECOMPRESS_LZMA=y
+CONFIG_DECOMPRESS_XZ=y
+CONFIG_DECOMPRESS_LZO=y
+CONFIG_DECOMPRESS_LZ4=y
+CONFIG_HAS_IOMEM=y
+CONFIG_HAS_IOPORT_MAP=y
+CONFIG_HAS_DMA=y
+CONFIG_CPU_RMAP=y
+CONFIG_DQL=y
+CONFIG_NLATTR=y
+CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
+# CONFIG_AVERAGE is not set
+# CONFIG_CORDIC is not set
+# CONFIG_DDR is not set
+CONFIG_ARCH_HAS_SG_CHAIN=y
--
1.8.5.5
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [RFC 3/7] linux-stubdomain: Build a disk image
2015-02-04 4:06 [RFC 0/7] RFC Linux-based QEMU-upstream stub domain Eric Shelton
2015-02-04 4:06 ` [RFC 1/7] linux-stubdomain: Compile QEMU Eric Shelton
2015-02-04 4:06 ` [RFC 2/7] linux-stubdomain: Compile Linux Eric Shelton
@ 2015-02-04 4:06 ` Eric Shelton
2015-02-06 15:57 ` Stefano Stabellini
2015-02-04 4:06 ` [RFC 4/7] libxl: Add "stubdomain_version" to domain_build_info Eric Shelton
` (4 subsequent siblings)
7 siblings, 1 reply; 43+ messages in thread
From: Eric Shelton @ 2015-02-04 4:06 UTC (permalink / raw)
To: xen-devel; +Cc: anthony.perard, Eric Shelton, Ian.Campbell, stefano.stabellini
This patch builds a disk image intended to be mounted as rootfs by the
Linux stub domain. It is assembled using dracut and genext2fs.
Signed-off-by: Eric Shelton <eshelton@pobox.com>
---
stubdom-linux/.gitignore | 4 ++
stubdom-linux/Makefile | 45 +++++++++++++++++++-
| 25 +++++++++++
| 7 +++
stubdom-linux/gen-stubdom-disk.sh | 89 +++++++++++++++++++++++++++++++++++++++
5 files changed, 168 insertions(+), 2 deletions(-)
create mode 100644 stubdom-linux/extra/initscript
create mode 100644 stubdom-linux/extra/qemu-ifup
create mode 100755 stubdom-linux/gen-stubdom-disk.sh
diff --git a/stubdom-linux/.gitignore b/stubdom-linux/.gitignore
index 891f0c8..b8f2e26 100644
--- a/stubdom-linux/.gitignore
+++ b/stubdom-linux/.gitignore
@@ -4,3 +4,7 @@
/linux-*.tar.xz
/linux-*/
/vmlinuz-stubdom
+/initramfs
+/stubdom-disk.img
+/dracut-???*
+/genext2fs-*
diff --git a/stubdom-linux/Makefile b/stubdom-linux/Makefile
index 31bfbee..a46f5b0 100644
--- a/stubdom-linux/Makefile
+++ b/stubdom-linux/Makefile
@@ -12,7 +12,19 @@ LINUX_V=linux-3.17.8
VMLINUZ=$(LINUX_V)/arch/x86/boot/bzImage
LINUX_URL=ftp://ftp.kernel.org/pub/linux/kernel/v3.x/$(LINUX_V).tar.xz
-all: $(VMLINUZ)
+DRACUT_URL="http://www.kernel.org/pub/linux/utils/boot/dracut"
+DRACUT_V=dracut-033
+
+GENEXT2FS_V = 1.4.1
+GENEXT2FS_URL="http://sourceforge.net/projects/genext2fs/files/genext2fs/$(GENEXT2FS_V)/genext2fs-$(GENEXT2FS_V).tar.gz/download"
+
+# Stubdom disk content
+STUBDOM_DISK_FILE= \
+ qemu-build/i386-softmmu/qemu-system-i386 \
+ extra/initscript \
+ extra/qemu-ifup
+
+all: $(VMLINUZ) stubdom-disk.img
qemu-build/Makefile:
export GIT=$(GIT); \
@@ -73,5 +85,34 @@ $(LINUX_V)/Makefile $(LINUX_V)/.config: $(LINUX_V).tar.xz
$(VMLINUZ): $(LINUX_V)/.config
$(MAKE) -C $(LINUX_V)
-install: $(VMLINUZ)
+$(DRACUT_V).tar.xz:
+ $(FETCHER) $@ $(DRACUT_URL)/$@
+
+DRACUT_INSTALL=$(CURDIR)/$(DRACUT_V)/dracut-install
+$(DRACUT_INSTALL): $(DRACUT_V).tar.xz
+ tar xf $<
+ $(MAKE) -C $(DRACUT_V) dracut-install
+
+GENEXT2FS = $(shell which genext2fs 2>/dev/null)
+ifeq ($(GENEXT2FS),)
+GENEXT2FS = $(CURDIR)/genext2fs-$(GENEXT2FS_V)/genext2fs
+endif
+
+genext2fs-$(GENEXT2FS_V).tar.gz:
+ $(FETCHER) $@ $(GENEXT2FS_URL)
+$(CURDIR)/genext2fs-$(GENEXT2FS_V)/genext2fs: genext2fs-$(GENEXT2FS_V).tar.gz
+ tar xf $<
+ cd genext2fs-$(GENEXT2FS_V) && ./configure
+ $(MAKE) -C genext2fs-$(GENEXT2FS_V)
+
+gen-stubdom-disk.sh: $(DRACUT_INSTALL) $(GENEXT2FS)
+
+export DRACUT_INSTALL
+export GENEXT2FS
+stubdom-disk.img: gen-stubdom-disk.sh $(STUBDOM_DISK_FILE)
+ env -u MAKELEVEL -u MAKEFLAGS -u MFLAGS ./$<
+ chmod a-w $@
+
+install: $(VMLINUZ) stubdom-disk.img
cp -f $(VMLINUZ) $(DESTDIR)/usr/local/lib/xen/boot/vmlinuz-stubdom
+ cp -f stubdom-disk.img $(DESTDIR)/usr/local/lib/xen/boot/
--git a/stubdom-linux/extra/initscript b/stubdom-linux/extra/initscript
new file mode 100644
index 0000000..a0f50ad
--- /dev/null
+++ b/stubdom-linux/extra/initscript
@@ -0,0 +1,25 @@
+#!/bin/busybox sh
+
+set -e
+set -x
+mount -t sysfs /sys /sys
+mount -t proc /proc /proc
+mount -t xenfs -o nodev /proc/xen /proc/xen
+
+if test -e /sys/class/net/eth0; then
+ ip link set eth0 address fe:ff:ff:ff:ff:fe
+ ip addr flush eth0
+ ip link set eth0 up
+ brctl addbr br0
+ brctl addif br0 eth0
+ ip link set br0 up
+else
+ echo "No network interface named eth0."
+ ls -l /sys/class/net/
+fi
+
+domid=$(/bin/xenstore-read "target")
+vm_path=$(xenstore-read "/local/domain/$domid/vm")
+dm_args=$(xenstore-read "$vm_path/image/dmargs")
+
+/bin/qemu $dm_args
--git a/stubdom-linux/extra/qemu-ifup b/stubdom-linux/extra/qemu-ifup
new file mode 100644
index 0000000..d71672b
--- /dev/null
+++ b/stubdom-linux/extra/qemu-ifup
@@ -0,0 +1,7 @@
+#! /bin/busybox sh
+
+ip link set "$1" down
+ip link set "$1" address fe:ff:ff:ff:ff:fd
+ip addr flush "$1"
+brctl addif br0 "$1"
+ip link set "$1" up
diff --git a/stubdom-linux/gen-stubdom-disk.sh b/stubdom-linux/gen-stubdom-disk.sh
new file mode 100755
index 0000000..c209cba
--- /dev/null
+++ b/stubdom-linux/gen-stubdom-disk.sh
@@ -0,0 +1,89 @@
+#!/bin/bash
+
+set -e
+umask 022
+
+script_qemu_ifup="extra/qemu-ifup"
+script_init="extra/initscript"
+
+XEN_ROOT="$(cd ..; pwd)"
+xenstore_libs="$XEN_ROOT/tools/xenstore"
+libxc_libs="$XEN_ROOT/tools/libxc"
+export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$xenstore_libs"
+export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$libxc_libs"
+
+initdir="`pwd`/initramfs/"
+
+rm -fr "$initdir"
+
+# Using dracut to gather the shared libraries
+# from https://dracut.wiki.kernel.org/index.php/Main_Page
+if ! test -x "$DRACUT_INSTALL"; then
+ echo DRACUT_INSTALL unset or incorrect >&2
+ exit 1
+fi
+if ! test -x "$GENEXT2FS"; then
+ if ! which genext2fs 2>&1 >/dev/null; then
+ echo genext2fs not found and GENEXT2FS unset >&2
+ exit 1
+ fi
+else
+ function genext2fs(){
+ "$GENEXT2FS" "$@"
+ }
+fi
+
+
+inst() {
+ [[ -e "${initdir}/${2:-$1}" ]] && return 0 # already there
+ "$DRACUT_INSTALL" -D "$initdir" -l "$@"
+}
+
+mkdir -p "$initdir"/{bin,etc,proc/xen,sys,lib,dev,tmp}
+
+echo "Building initrd in $initdir"
+inst busybox /bin/busybox
+make DESTDIR="$initdir" -C qemu-build install
+# this gather libs install on the system for qemu
+inst "$initdir/bin/qemu-system-i386" /bin/qemu
+inst "$XEN_ROOT/tools/xenstore/xenstore-read" "/bin/xenstore-read"
+inst "$script_qemu_ifup" "/etc/qemu-ifup"
+chmod +x "$initdir/etc/qemu-ifup"
+inst "$script_init" "/init"
+chmod 755 "$initdir/init"
+
+ln -s busybox "$initdir/bin/mount"
+
+for d in "/usr/lib" "$xenstore_libs" "$libxc_libs"; do
+ d="$initdir/$d"
+ if test -d "$d"; then
+ mv "$d"/* "$initdir/lib64/"
+ if test -L "$d"; then
+ rm "$d"
+ else
+ rmdir --ignore-fail-on-non-empty -p "$d"
+ fi
+ fi
+done
+
+mv "$initdir/lib64/gcc"/*/*/* "$initdir/lib64/"
+rm -rf "$initdir/lib64/gcc"
+
+mkdir -p "$initdir/usr"
+ln -s /lib "$initdir/usr/lib"
+
+if false; then
+ IMAGE="./initramfs.cpio"
+ rm -f "$IMAGE"
+ (cd "$initdir"; find . | cpio -H newc --quiet -o) >| "$IMAGE" || exit 1
+ gzip -f "$IMAGE"
+else # ext2 fs using:
+ stubdom_disk=stubdom-disk.img
+ rm -f "$stubdom_disk"
+ genext2fs \
+ --root "$initdir" \
+ --size-in-blocks $(($(du -s "$initdir"|cut -f1)+2000)) \
+ --reserved-percentage 0 \
+ --squash \
+ "$stubdom_disk"
+fi
--
1.8.5.5
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [RFC 4/7] libxl: Add "stubdomain_version" to domain_build_info.
2015-02-04 4:06 [RFC 0/7] RFC Linux-based QEMU-upstream stub domain Eric Shelton
` (2 preceding siblings ...)
2015-02-04 4:06 ` [RFC 3/7] linux-stubdomain: Build a disk image Eric Shelton
@ 2015-02-04 4:06 ` Eric Shelton
2015-02-06 16:06 ` Stefano Stabellini
2015-02-09 9:11 ` Ian Campbell
2015-02-04 4:06 ` [RFC 5/7] libxl: Handle Linux stubdomain specific QEMU options Eric Shelton
` (3 subsequent siblings)
7 siblings, 2 replies; 43+ messages in thread
From: Eric Shelton @ 2015-02-04 4:06 UTC (permalink / raw)
To: xen-devel; +Cc: anthony.perard, Eric Shelton, Ian.Campbell, stefano.stabellini
This enum gives the ability to select between a MiniOS-based QEMU
traditional stub domain and a Linux-based QEMU upstream stub domain. To
use the Linux-based stubdomain, the following two lines should be
included in the appropriate xl.cfg file:
device_model_version="qemu-xen"
device_model_stubdomain_override=1
To use the MiniOS-based stubdomain, the following is used instead:
device_model_version="qemu-xen-traditional"
device_model_stubdomain_override=1
Signed-off-by: Eric Shelton <eshelton@pobox.com>
---
tools/libxl/libxl_create.c | 34 +++++++++++++++++++++++++++++-----
tools/libxl/libxl_types.idl | 7 +++++++
2 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 98687bd..15258fa 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -181,12 +181,36 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
}
if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
- b_info->device_model_version !=
- LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
libxl_defbool_val(b_info->device_model_stubdomain)) {
- LIBXL__LOG(CTX, XTL_ERROR,
- "device model stubdomains require \"qemu-xen-traditional\"");
- return ERROR_INVAL;
+ if (!b_info->stubdomain_version) {
+ switch (b_info->device_model_version) {
+ case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+ b_info->stubdomain_version = LIBXL_STUBDOMAIN_VERSION_MINIOS;
+ break;
+ case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+ b_info->stubdomain_version = LIBXL_STUBDOMAIN_VERSION_LINUX;
+ break;
+ default: abort();
+ }
+ }
+
+ switch (b_info->device_model_version) {
+ case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+ if (b_info->stubdomain_version != LIBXL_STUBDOMAIN_VERSION_MINIOS) {
+ LIBXL__LOG(CTX, XTL_ERROR,
+ "\"qemu-xen-traditional\" require \"minios\" as stubdomain");
+ return ERROR_INVAL;
+ }
+ break;
+ case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+ if (b_info->stubdomain_version != LIBXL_STUBDOMAIN_VERSION_LINUX) {
+ LIBXL__LOG(CTX, XTL_ERROR,
+ "\"qemu-xen\" require \"linux\" as stubdomain");
+ return ERROR_INVAL;
+ }
+ break;
+ default: abort();
+ }
}
if (!b_info->max_vcpus)
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 02be466..8d0ac3b 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -83,6 +83,12 @@ libxl_device_model_version = Enumeration("device_model_version", [
(2, "QEMU_XEN"), # Upstream based qemu-xen device model
])
+# Give the kernel running in the stub-domain
+libxl_stubdomain_version = Enumeration("stubdomain_version", [
+ (1, "MINIOS"),
+ (2, "LINUX"),
+ ])
+
libxl_console_type = Enumeration("console_type", [
(0, "UNKNOWN"),
(1, "SERIAL"),
@@ -379,6 +385,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
("device_model_version", libxl_device_model_version),
("device_model_stubdomain", libxl_defbool),
+ ("stubdomain_version", libxl_stubdomain_version),
# if you set device_model you must set device_model_version too
("device_model", string),
("device_model_ssidref", uint32),
--
1.8.5.5
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [RFC 5/7] libxl: Handle Linux stubdomain specific QEMU options.
2015-02-04 4:06 [RFC 0/7] RFC Linux-based QEMU-upstream stub domain Eric Shelton
` (3 preceding siblings ...)
2015-02-04 4:06 ` [RFC 4/7] libxl: Add "stubdomain_version" to domain_build_info Eric Shelton
@ 2015-02-04 4:06 ` Eric Shelton
2015-02-06 16:17 ` Stefano Stabellini
2015-02-04 4:06 ` [RFC 6/7] libxl: Build the domain with a Linux based stubdomain Eric Shelton
` (2 subsequent siblings)
7 siblings, 1 reply; 43+ messages in thread
From: Eric Shelton @ 2015-02-04 4:06 UTC (permalink / raw)
To: xen-devel; +Cc: anthony.perard, Eric Shelton, Ian.Campbell, stefano.stabellini
This patch creates an appropriate command line for the QEMU instance
running in a Linux-based stubdomain.
NOTE: a number of items are not currently implemented for Linux-based
stubdomains, such as:
- save/restore
- QMP socket
- graphics output (e.g., VNC)
Signed-off-by: Eric Shelton <eshelton@pobox.com>
---
tools/libxl/libxl_dm.c | 86 ++++++++++++++++++++++++++++++++++----------------
1 file changed, 58 insertions(+), 28 deletions(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 8599a6a..68d5886 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -20,9 +20,12 @@
#include "libxl_internal.h"
#include <xen/hvm/e820.h>
-static const char *libxl_tapif_script(libxl__gc *gc)
+static const char *libxl_tapif_script(libxl__gc *gc,
+ const libxl_domain_build_info *info)
{
#if defined(__linux__) || defined(__FreeBSD__)
+ if (info->stubdomain_version == LIBXL_STUBDOMAIN_VERSION_LINUX)
+ return libxl__sprintf(gc, "/etc/qemu-ifup");
return libxl__strdup(gc, "no");
#else
return libxl__sprintf(gc, "%s/qemu-ifup", libxl__xen_script_dir_path());
@@ -307,8 +310,8 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
"tap,vlan=%d,ifname=%s,bridge=%s,"
"script=%s,downscript=%s",
nics[i].devid, ifname, nics[i].bridge,
- libxl_tapif_script(gc),
- libxl_tapif_script(gc)),
+ libxl_tapif_script(gc, b_info),
+ libxl_tapif_script(gc, b_info)),
NULL);
ioemu_nics++;
}
@@ -430,6 +433,7 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
int i, connection, devid;
uint64_t ram_size;
const char *path, *chardev;
+ bool is_stubdom = libxl_defbool_val(b_info->device_model_stubdomain);
dm_args = flexarray_make(gc, 16, 1);
@@ -437,15 +441,18 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
"-xen-domid",
libxl__sprintf(gc, "%d", guest_domid), NULL);
- flexarray_append(dm_args, "-chardev");
- flexarray_append(dm_args,
- libxl__sprintf(gc, "socket,id=libxl-cmd,"
- "path=%s/qmp-libxl-%d,server,nowait",
- libxl__run_dir_path(), guest_domid));
-
- flexarray_append(dm_args, "-no-shutdown");
- flexarray_append(dm_args, "-mon");
- flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
+ /* There is currently no way to access the QMP socket in the stubdom */
+ if (!is_stubdom) {
+ flexarray_append(dm_args, "-chardev");
+ flexarray_append(dm_args,
+ libxl__sprintf(gc, "socket,id=libxl-cmd,"
+ "path=%s/qmp-libxl-%d,server,nowait",
+ libxl__run_dir_path(), guest_domid));
+
+ flexarray_append(dm_args, "-no-shutdown");
+ flexarray_append(dm_args, "-mon");
+ flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
+ }
for (i = 0; i < guest_config->num_channels; i++) {
connection = guest_config->channels[i].connection;
@@ -483,7 +490,7 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
flexarray_vappend(dm_args, "-name", c_info->name, NULL);
}
- if (vnc) {
+ if (vnc && !is_stubdom) {
char *vncarg = NULL;
flexarray_append(dm_args, "-vnc");
@@ -524,7 +531,7 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
flexarray_append(dm_args, vncarg);
}
- if (sdl) {
+ if (sdl && !is_stubdom) {
flexarray_append(dm_args, "-sdl");
/* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
}
@@ -552,10 +559,19 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
return NULL;
}
if (b_info->u.hvm.serial) {
- flexarray_vappend(dm_args,
- "-serial", b_info->u.hvm.serial, NULL);
+ if (is_stubdom) {
+ flexarray_vappend(dm_args,
+ "-serial", "/dev/hvc1", NULL);
+ } else {
+ flexarray_vappend(dm_args,
+ "-serial", b_info->u.hvm.serial, NULL);
+ }
} else if (b_info->u.hvm.serial_list) {
char **p;
+ if (is_stubdom) {
+ flexarray_vappend(dm_args,
+ "-serial", "/dev/hvc1", NULL);
+ }
for (p = b_info->u.hvm.serial_list;
*p;
p++) {
@@ -570,7 +586,7 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
flexarray_append(dm_args, "-nographic");
}
- if (libxl_defbool_val(b_info->u.hvm.spice.enable)) {
+ if (libxl_defbool_val(b_info->u.hvm.spice.enable) && !is_stubdom) {
const libxl_spice_info *spice = &b_info->u.hvm.spice;
char *spiceoptions = dm_spice_options(gc, spice);
if (!spiceoptions)
@@ -700,8 +716,8 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
"type=tap,id=net%d,ifname=%s,"
"script=%s,downscript=%s",
nics[i].devid, ifname,
- libxl_tapif_script(gc),
- libxl_tapif_script(gc)));
+ libxl_tapif_script(gc, b_info),
+ libxl_tapif_script(gc, b_info)));
ioemu_nics++;
}
}
@@ -789,6 +805,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
drive = libxl__sprintf
(gc, "if=ide,index=%d,media=cdrom,cache=writeback,id=ide-%i",
disk, dev_number);
+ else if (b_info->stubdomain_version == LIBXL_STUBDOMAIN_VERSION_LINUX)
+ drive = libxl__sprintf
+ (gc, "file=%s,if=ide,index=%d,media=cdrom,cache=writeback,format=%s,id=ide-%i",
+ "/dev/xvdc", disk, "host_cdrom", dev_number);
else
drive = libxl__sprintf
(gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s,cache=writeback,id=ide-%i",
@@ -824,10 +844,16 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
drive = libxl__sprintf
(gc, "file=%s,if=scsi,bus=0,unit=%d,format=%s,cache=writeback",
pdev_path, disk, format);
- else if (disk < 4)
- drive = libxl__sprintf
- (gc, "file=%s,if=ide,index=%d,media=disk,format=%s,cache=writeback",
- pdev_path, disk, format);
+ else if (disk < 4) {
+ if (b_info->stubdomain_version == LIBXL_STUBDOMAIN_VERSION_LINUX)
+ drive = libxl__sprintf
+ (gc, "file=%s,if=ide,index=%d,media=disk,cache=writeback,format=%s",
+ "/dev/xvda", disk, "host_device");
+ else
+ drive = libxl__sprintf
+ (gc, "file=%s,if=ide,index=%d,media=disk,format=%s,cache=writeback",
+ pdev_path, disk, format);
+ }
else
continue; /* Do not emulate this disk */
}
@@ -854,7 +880,7 @@ static char ** libxl__build_device_model_args(libxl__gc *gc,
const libxl_domain_config *guest_config,
const libxl__domain_build_state *state,
int *dm_state_fd)
-/* dm_state_fd may be NULL iff caller knows we are using old stubdom
+/* dm_state_fd may be NULL iff caller knows we are using stubdom
* and therefore will be passing a filename rather than a fd. */
{
libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -865,8 +891,10 @@ static char ** libxl__build_device_model_args(libxl__gc *gc,
guest_domid, guest_config,
state);
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
- assert(dm_state_fd != NULL);
- assert(*dm_state_fd < 0);
+ if (!libxl_defbool_val(guest_config->b_info.device_model_stubdomain)) {
+ assert(dm_state_fd != NULL);
+ assert(*dm_state_fd < 0);
+ }
return libxl__build_device_model_args_new(gc, dm,
guest_domid, guest_config,
state, dm_state_fd);
@@ -922,7 +950,7 @@ static int libxl__vfb_and_vkb_from_hvm_guest_config(libxl__gc *gc,
static int libxl__write_stub_dmargs(libxl__gc *gc,
int dm_domid, int guest_domid,
- char **args)
+ char **args, bool linux_stubdom)
{
libxl_ctx *ctx = libxl__gc_owner(gc);
int i;
@@ -950,7 +978,9 @@ static int libxl__write_stub_dmargs(libxl__gc *gc,
i = 1;
dmargs[0] = '\0';
while (args[i] != NULL) {
- if (strcmp(args[i], "-sdl") && strcmp(args[i], "-M") && strcmp(args[i], "xenfv")) {
+ if (linux_stubdom ||
+ (strcmp(args[i], "-sdl") &&
+ strcmp(args[i], "-M") && strcmp(args[i], "xenfv"))) {
strcat(dmargs, " ");
strcat(dmargs, args[i]);
}
--
1.8.5.5
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [RFC 6/7] libxl: Build the domain with a Linux based stubdomain
2015-02-04 4:06 [RFC 0/7] RFC Linux-based QEMU-upstream stub domain Eric Shelton
` (4 preceding siblings ...)
2015-02-04 4:06 ` [RFC 5/7] libxl: Handle Linux stubdomain specific QEMU options Eric Shelton
@ 2015-02-04 4:06 ` Eric Shelton
2015-02-06 16:33 ` Stefano Stabellini
2015-02-04 4:06 ` [RFC 7/7] libxl: Wait for QEMU startup in stubdomain Eric Shelton
2015-02-06 15:42 ` [RFC 0/7] RFC Linux-based QEMU-upstream stub domain Stefano Stabellini
7 siblings, 1 reply; 43+ messages in thread
From: Eric Shelton @ 2015-02-04 4:06 UTC (permalink / raw)
To: xen-devel; +Cc: anthony.perard, Eric Shelton, Ian.Campbell, stefano.stabellini
This will build a Linux-based stubdomain with QEMU upstream.
Signed-off-by: Eric Shelton <eshelton@pobox.com>
---
tools/libxl/libxl.c | 25 ++++++++--
tools/libxl/libxl_create.c | 7 ++-
tools/libxl/libxl_dm.c | 108 ++++++++++++++++++++++++++++++++++++-------
tools/libxl/libxl_internal.c | 22 +++++++++
tools/libxl/libxl_internal.h | 4 ++
5 files changed, 145 insertions(+), 21 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 82227e8..85cf5eb 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1757,8 +1757,17 @@ static int libxl__primary_console_find(libxl_ctx *ctx, uint32_t domid_vm,
if (stubdomid) {
*domid = stubdomid;
- *cons_num = STUBDOM_CONSOLE_SERIAL;
*type = LIBXL_CONSOLE_TYPE_PV;
+ switch (libxl__stubdomain_version_running(gc, stubdomid)) {
+ case LIBXL_STUBDOMAIN_VERSION_MINIOS:
+ *cons_num = STUBDOM_CONSOLE_SERIAL;
+ break;
+ case LIBXL_STUBDOMAIN_VERSION_LINUX:
+ *cons_num = 1;
+ break;
+ default:
+ abort();
+ }
} else {
switch (libxl__domain_type(gc, domid_vm)) {
case LIBXL_DOMAIN_TYPE_HVM:
@@ -4927,8 +4936,18 @@ int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
switch (b_info->type) {
case LIBXL_DOMAIN_TYPE_HVM:
*need_memkb += b_info->shadow_memkb + LIBXL_HVM_EXTRA_MEMORY;
- if (libxl_defbool_val(b_info->device_model_stubdomain))
- *need_memkb += 32 * 1024;
+ if (libxl_defbool_val(b_info->device_model_stubdomain)) {
+ switch (b_info->stubdomain_version) {
+ case LIBXL_STUBDOMAIN_VERSION_MINIOS:
+ *need_memkb += 32 * 1024;
+ break;
+ case LIBXL_STUBDOMAIN_VERSION_LINUX:
+ *need_memkb += LIBXL_LINUX_STUBDOM_MEM * 1024;
+ break;
+ default:
+ abort();
+ }
+ }
break;
case LIBXL_DOMAIN_TYPE_PV:
*need_memkb += b_info->shadow_memkb + LIBXL_PV_EXTRA_MEMORY;
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 15258fa..b2c903e 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1358,7 +1358,12 @@ static void domcreate_devmodel_started(libxl__egc *egc,
if (dcs->dmss.dm.guest_domid) {
if (d_config->b_info.device_model_version
== LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
- libxl__qmp_initializations(gc, domid, d_config);
+ if (!libxl_defbool_val(d_config->b_info.device_model_stubdomain)) {
+ libxl__qmp_initializations(gc, domid, d_config);
+ } else {
+ int stubdom_domid = dcs->dmss.pvqemu.guest_domid;
+ libxl__qmp_initializations(gc, stubdom_domid, d_config);
+ }
}
}
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 68d5886..d03be4a 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1000,6 +1000,16 @@ retry_transaction:
return 0;
}
+static int libxl__store_libxl_entry(libxl__gc *gc, uint32_t domid,
+ const char *name, const char *value)
+{
+ char *path = NULL;
+
+ path = libxl__xs_libxl_path(gc, domid);
+ path = libxl__sprintf(gc, "%s/%s", path, name);
+ return libxl__xs_write(gc, XBT_NULL, path, "%s", value);
+}
+
static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
libxl__dm_spawn_state *stubdom_dmss,
int rc);
@@ -1030,6 +1040,7 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
char **args;
struct xs_permissions perm[2];
xs_transaction_t t;
+ libxl_device_disk disk_stub;
/* convenience aliases */
libxl_domain_config *const dm_config = &sdss->dm_config;
@@ -1038,10 +1049,14 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
libxl__domain_build_state *const d_state = sdss->dm.build_state;
libxl__domain_build_state *const stubdom_state = &sdss->dm_state;
- if (guest_config->b_info.device_model_version !=
- LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
- ret = ERROR_INVAL;
- goto out;
+ assert(libxl_defbool_val(guest_config->b_info.device_model_stubdomain));
+
+ if (guest_config->b_info.stubdomain_version == LIBXL_STUBDOMAIN_VERSION_LINUX) {
+ if (d_state->saved_state) {
+ LOG(ERROR, "Save/Restore not supported yet with Linux Stubdom.");
+ ret = -1;
+ goto out;
+ }
}
sdss->pvqemu.guest_domid = 0;
@@ -1062,7 +1077,16 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
libxl_domain_build_info_init_type(&dm_config->b_info, LIBXL_DOMAIN_TYPE_PV);
dm_config->b_info.max_vcpus = 1;
- dm_config->b_info.max_memkb = 32 * 1024;
+ switch (guest_config->b_info.stubdomain_version) {
+ case LIBXL_STUBDOMAIN_VERSION_MINIOS:
+ dm_config->b_info.max_memkb = 32 * 1024;
+ break;
+ case LIBXL_STUBDOMAIN_VERSION_LINUX:
+ dm_config->b_info.max_memkb = LIBXL_LINUX_STUBDOM_MEM * 1024;
+ break;
+ default:
+ abort();
+ }
dm_config->b_info.target_memkb = dm_config->b_info.max_memkb;
dm_config->b_info.u.pv.features = "";
@@ -1096,10 +1120,32 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
dm_config->vkbs = vkb;
dm_config->num_vkbs = 1;
- stubdom_state->pv_kernel.path
- = libxl__abs_path(gc, "ioemu-stubdom.gz", libxl__xenfirmwaredir_path());
- stubdom_state->pv_cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
- stubdom_state->pv_ramdisk.path = "";
+ switch (guest_config->b_info.stubdomain_version) {
+ case LIBXL_STUBDOMAIN_VERSION_MINIOS:
+ stubdom_state->pv_kernel.path
+ = libxl__abs_path(gc, "ioemu-stubdom.gz", libxl__xenfirmwaredir_path());
+ stubdom_state->pv_cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
+ stubdom_state->pv_ramdisk.path = "";
+ break;
+ case LIBXL_STUBDOMAIN_VERSION_LINUX:
+ libxl_device_disk_init(&disk_stub);
+ disk_stub.readwrite = 0;
+ disk_stub.format = LIBXL_DISK_FORMAT_RAW;
+ disk_stub.is_cdrom = 0;
+ disk_stub.vdev = "xvdz";
+ disk_stub.pdev_path = libxl__abs_path(gc, "stubdom-disk.img",
+ libxl__xenfirmwaredir_path());
+ ret = libxl__device_disk_setdefault(gc, &disk_stub);
+ if (ret) goto out;
+ stubdom_state->pv_kernel.path
+ = libxl__abs_path(gc, "vmlinuz-stubdom", libxl__xenfirmwaredir_path());
+ stubdom_state->pv_cmdline
+ = "debug console=hvc0 root=/dev/xvdz ro init=/init";
+ stubdom_state->pv_ramdisk.path = "";
+ break;
+ default:
+ abort();
+ }
/* fixme: this function can leak the stubdom if it fails */
ret = libxl__domain_make(gc, &dm_config->c_info, &sdss->pvqemu.guest_domid);
@@ -1117,7 +1163,12 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
goto out;
}
- libxl__write_stub_dmargs(gc, dm_domid, guest_domid, args);
+ libxl__store_libxl_entry(gc, guest_domid, "dm-version",
+ libxl_device_model_version_to_string(dm_config->b_info.device_model_version));
+ libxl__store_libxl_entry(gc, dm_domid, "stubdom-version",
+ libxl_stubdomain_version_to_string(guest_config->b_info.stubdomain_version));
+ libxl__write_stub_dmargs(gc, dm_domid, guest_domid, args,
+ guest_config->b_info.stubdomain_version == LIBXL_STUBDOMAIN_VERSION_LINUX);
libxl__xs_write(gc, XBT_NULL,
libxl__sprintf(gc, "%s/image/device-model-domid",
libxl__xs_get_dompath(gc, guest_domid)),
@@ -1126,6 +1177,15 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
libxl__sprintf(gc, "%s/target",
libxl__xs_get_dompath(gc, dm_domid)),
"%d", guest_domid);
+ if (guest_config->b_info.stubdomain_version == LIBXL_STUBDOMAIN_VERSION_LINUX) {
+ /* qemu-xen is used as a dm in the stubdomain, so we set the bios
+ * accroding to this */
+ libxl__xs_write(gc, XBT_NULL,
+ libxl__sprintf(gc, "%s/hvmloader/bios",
+ libxl__xs_get_dompath(gc, guest_domid)),
+ "%s",
+ libxl_bios_type_to_string(LIBXL_BIOS_TYPE_SEABIOS));
+ }
ret = xc_domain_set_target(ctx->xch, dm_domid, guest_domid);
if (ret<0) {
LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
@@ -1153,6 +1213,10 @@ retry_transaction:
libxl__multidev_begin(ao, &sdss->multidev);
sdss->multidev.callback = spawn_stub_launch_dm;
+ if (guest_config->b_info.stubdomain_version == LIBXL_STUBDOMAIN_VERSION_LINUX) {
+ libxl__ao_device *aodev = libxl__multidev_prepare(&sdss->multidev);
+ libxl__device_disk_add(egc, dm_domid, &disk_stub, aodev);
+ }
libxl__add_disks(egc, ao, dm_domid, dm_config, &sdss->multidev);
libxl__multidev_prepared(egc, &sdss->multidev, 0);
@@ -1201,6 +1265,10 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
if (ret)
goto out;
+ if (guest_config->b_info.stubdomain_version == LIBXL_STUBDOMAIN_VERSION_LINUX) {
+ /* no special console for save/restore, only the logging console */
+ num_console = 1;
+ }
if (guest_config->b_info.u.hvm.serial)
num_console++;
@@ -1229,14 +1297,20 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
free(filename);
break;
case STUBDOM_CONSOLE_SAVE:
- console[i].output = libxl__sprintf(gc, "file:%s",
- libxl__device_model_savefile(gc, guest_domid));
- break;
+ if (guest_config->b_info.stubdomain_version
+ == LIBXL_STUBDOMAIN_VERSION_MINIOS) {
+ console[i].output = libxl__sprintf(gc, "file:%s",
+ libxl__device_model_savefile(gc, guest_domid));
+ break;
+ }
case STUBDOM_CONSOLE_RESTORE:
- if (d_state->saved_state)
- console[i].output =
- libxl__sprintf(gc, "pipe:%s", d_state->saved_state);
- break;
+ if (guest_config->b_info.stubdomain_version
+ == LIBXL_STUBDOMAIN_VERSION_MINIOS) {
+ if (d_state->saved_state)
+ console[i].output =
+ libxl__sprintf(gc, "pipe:%s", d_state->saved_state);
+ break;
+ }
default:
console[i].output = "pty";
break;
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index ddc68ab..d38e23d 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -364,6 +364,28 @@ int libxl__device_model_version_running(libxl__gc *gc, uint32_t domid)
return value;
}
+int libxl__stubdomain_version_running(libxl__gc *gc, uint32_t domid)
+{
+ char *path = NULL;
+ char *stub_version = NULL;
+ libxl_stubdomain_version value;
+
+ path = libxl__xs_libxl_path(gc, domid);
+ path = libxl__sprintf(gc, "%s/stubdom-version", path);
+ stub_version = libxl__xs_read(gc, XBT_NULL, path);
+ if (!stub_version) {
+ return LIBXL_STUBDOMAIN_VERSION_MINIOS;
+ }
+
+ if (libxl_stubdomain_version_from_string(stub_version, &value) < 0) {
+ libxl_ctx *ctx = libxl__gc_owner(gc);
+ LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+ "fatal: %s contain a wrong value (%s)", path, stub_version);
+ return -1;
+ }
+ return value;
+}
+
int libxl__hotplug_settings(libxl__gc *gc, xs_transaction_t t)
{
int rc = 0;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 934465a..8755022 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -102,6 +102,7 @@
#define STUBDOM_CONSOLE_RESTORE 2
#define STUBDOM_CONSOLE_SERIAL 3
#define STUBDOM_SPECIAL_CONSOLES 3
+#define LIBXL_LINUX_STUBDOM_MEM 128
#define TAP_DEVICE_SUFFIX "-emu"
#define DISABLE_UDEV_PATH "libxl/disable_udev"
#define DOMID_XS_PATH "domid"
@@ -1794,6 +1795,9 @@ _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc_opt, const char *s);
_hidden int libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
/* Return the system-wide default device model */
_hidden libxl_device_model_version libxl__default_device_model(libxl__gc *gc);
+ /* Based on /libxl/$domid/stubdom-version xenstore key
+ * default is minios */
+_hidden int libxl__stubdomain_version_running(libxl__gc *gc, uint32_t domid);
/* Check how executes hotplug script currently */
int libxl__hotplug_settings(libxl__gc *gc, xs_transaction_t t);
--
1.8.5.5
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [RFC 7/7] libxl: Wait for QEMU startup in stubdomain
2015-02-04 4:06 [RFC 0/7] RFC Linux-based QEMU-upstream stub domain Eric Shelton
` (5 preceding siblings ...)
2015-02-04 4:06 ` [RFC 6/7] libxl: Build the domain with a Linux based stubdomain Eric Shelton
@ 2015-02-04 4:06 ` Eric Shelton
2015-02-06 11:16 ` Wei Liu
2015-02-06 15:42 ` [RFC 0/7] RFC Linux-based QEMU-upstream stub domain Stefano Stabellini
7 siblings, 1 reply; 43+ messages in thread
From: Eric Shelton @ 2015-02-04 4:06 UTC (permalink / raw)
To: xen-devel; +Cc: anthony.perard, Eric Shelton, Ian.Campbell, stefano.stabellini
To ensure the QEMU instance in a stubdomain is running before we unpause
an HVM guest that relies on it for a device model, we do a xenstore wait
on QEMU's indiction that it is running.
Signed-off-by: Eric Shelton <eshelton@pobox.com>
---
tools/libxl/libxl_dm.c | 46 +++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index d03be4a..ad8d1dc 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1361,6 +1361,39 @@ out:
stubdom_pvqemu_cb(egc, &sdss->multidev, rc);
}
+static void stub_dm_watch_event(libxl__egc *egc, libxl__xswait_state *xswa,
+ int rc, const char *p)
+{
+ EGC_GC;
+ libxl__spawn_state *spawn = CONTAINER_OF(xswa, libxl__spawn_state, xswait);
+ libxl__dm_spawn_state *pvqemu =
+ CONTAINER_OF(spawn, libxl__dm_spawn_state, spawn);
+ libxl__stub_dm_spawn_state *sdss =
+ CONTAINER_OF(pvqemu, libxl__stub_dm_spawn_state, pvqemu);
+ uint32_t dm_domid = sdss->pvqemu.guest_domid;
+
+ if (rc) {
+ if (rc == ERROR_TIMEDOUT)
+ LIBXL__LOG(CTX, XTL_DEBUG, "%s: startup timed out", xswa->what);
+ if (dm_domid) {
+ sdss->dis.ao = sdss->dm.spawn.ao;
+ sdss->dis.domid = dm_domid;
+ sdss->dis.callback = spaw_stubdom_pvqemu_destroy_cb;
+ libxl__destroy_domid(egc, &sdss->dis);
+ }
+ return;
+ }
+
+ if (!p)
+ return;
+
+ if (strcmp(p, "running"))
+ return;
+
+ libxl__xswait_stop(gc, xswa);
+ sdss->callback(egc, &sdss->dm, rc);
+}
+
static void stubdom_pvqemu_cb(libxl__egc *egc,
libxl__multidev *multidev,
int rc)
@@ -1368,12 +1401,24 @@ static void stubdom_pvqemu_cb(libxl__egc *egc,
libxl__stub_dm_spawn_state *sdss = CONTAINER_OF(multidev, *sdss, multidev);
STATE_AO_GC(sdss->dm.spawn.ao);
uint32_t dm_domid = sdss->pvqemu.guest_domid;
+ libxl__xswait_state *xswait = &sdss->pvqemu.spawn.xswait;
if (rc) {
LOGE(ERROR, "error connecting nics devices");
goto out;
}
+ /* wait for PV stubdom QEMU instance to be ready */
+ libxl__xswait_init(xswait);
+ xswait->ao = sdss->dm.spawn.ao;
+ xswait->what = GCSPRINTF("stub domain %d startup", dm_domid);
+ xswait->path = GCSPRINTF("/local/domain/0/device-model/%d/state",
+ sdss->dm.guest_domid);
+ xswait->timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000;
+ xswait->callback = stub_dm_watch_event;
+ rc = libxl__xswait_start(gc, xswait);
+ if (rc) goto out;
+
rc = libxl_domain_unpause(CTX, dm_domid);
if (rc) goto out;
@@ -1387,7 +1432,6 @@ static void stubdom_pvqemu_cb(libxl__egc *egc,
return;
}
}
- sdss->callback(egc, &sdss->dm, rc);
}
static void spawn_stubdom_pvqemu_destroy_cb(libxl__egc *egc,
--
1.8.5.5
^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: [RFC 7/7] libxl: Wait for QEMU startup in stubdomain
2015-02-04 4:06 ` [RFC 7/7] libxl: Wait for QEMU startup in stubdomain Eric Shelton
@ 2015-02-06 11:16 ` Wei Liu
2015-02-06 13:56 ` Eric Shelton
0 siblings, 1 reply; 43+ messages in thread
From: Wei Liu @ 2015-02-06 11:16 UTC (permalink / raw)
To: Eric Shelton
Cc: anthony.perard, xen-devel, wei.liu2, Ian.Campbell, stefano.stabellini
Thanks for posting.
On Tue, Feb 03, 2015 at 11:06:15PM -0500, Eric Shelton wrote:
[...]
> @@ -1368,12 +1401,24 @@ static void stubdom_pvqemu_cb(libxl__egc *egc,
> libxl__stub_dm_spawn_state *sdss = CONTAINER_OF(multidev, *sdss, multidev);
> STATE_AO_GC(sdss->dm.spawn.ao);
> uint32_t dm_domid = sdss->pvqemu.guest_domid;
> + libxl__xswait_state *xswait = &sdss->pvqemu.spawn.xswait;
>
> if (rc) {
> LOGE(ERROR, "error connecting nics devices");
> goto out;
> }
>
> + /* wait for PV stubdom QEMU instance to be ready */
> + libxl__xswait_init(xswait);
> + xswait->ao = sdss->dm.spawn.ao;
> + xswait->what = GCSPRINTF("stub domain %d startup", dm_domid);
> + xswait->path = GCSPRINTF("/local/domain/0/device-model/%d/state",
> + sdss->dm.guest_domid);
FWIW we are now experiencing problem with this startup protocol (not
Linux stubdom specific) -- that path that libxl waiting for is wrong.
Unfortunately this problem can't be solved without putting in
significant effort and time (involves redesign of protocol and handle
all the compatibility issues). We can't say for sure when the solution
is going to land.
Also upstream QEMU stubdom, as you already notice, doesn't have a
critical functionality -- save / restore. Adding that in might involve
upstreaming some changes to QEMU, which has a time frame that is out of
our control. So my hunch is that we're not going to make it in time for
4.6. :-/
Wei.
> + xswait->timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000;
> + xswait->callback = stub_dm_watch_event;
> + rc = libxl__xswait_start(gc, xswait);
> + if (rc) goto out;
> +
> rc = libxl_domain_unpause(CTX, dm_domid);
> if (rc) goto out;
>
> @@ -1387,7 +1432,6 @@ static void stubdom_pvqemu_cb(libxl__egc *egc,
> return;
> }
> }
> - sdss->callback(egc, &sdss->dm, rc);
> }
>
> static void spawn_stubdom_pvqemu_destroy_cb(libxl__egc *egc,
> --
> 1.8.5.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 7/7] libxl: Wait for QEMU startup in stubdomain
2015-02-06 11:16 ` Wei Liu
@ 2015-02-06 13:56 ` Eric Shelton
2015-02-06 14:59 ` Wei Liu
0 siblings, 1 reply; 43+ messages in thread
From: Eric Shelton @ 2015-02-06 13:56 UTC (permalink / raw)
To: Wei Liu; +Cc: Anthony PERARD, xen-devel, Ian Campbell, Stefano Stabellini
On Fri, Feb 6, 2015 at 6:16 AM, Wei Liu <wei.liu2@citrix.com> wrote:
> Thanks for posting.
>
> ...
>
> FWIW we are now experiencing problem with this startup protocol (not
> Linux stubdom specific) -- that path that libxl waiting for is wrong.
I simply used the code already present in the QEMU upstream code,
which is writing to that particular ath to indicate "running." Since
it is distinct from the path used by the QEMU instance running in
Dom0, it works for my intended purpose: ensuring the device model is
running before unpausing the HVM guest. When you say it is "wrong,"
is that just because you ultimately intend to rearchitect this and use
something different? If so, maybe the path I am using is "good
enough" until that happens. Otherwise, can you suggest a better path
or mechanism?
> Unfortunately this problem can't be solved without putting in
> significant effort and time (involves redesign of protocol and handle
> all the compatibility issues). We can't say for sure when the solution
> is going to land.
I noticed some discussion about this on xen-devel. Unfortunately, I
was unable to find anything that laid out specifically what the
problems are - can you point me to a bug report or such? The libxl
startup code - with callbacks on top of callbacks, callbacks within
callbacks, and callbacks stashed away in little places only to be
called _much_ later - is really convoluted, I suspect particularly so
for stubdom startup. I am not surprised it got broken - who can
remember how it works?
While working on these patches reviving Anthony's work, I consistently
ran into HVM starup problems with QEMU upstream in a stub domain (it
always failed). What I could not figure out is why QEMU-traditional
did not have a similar problem; it seemed to me that the same race
existed for QEMU-traditional stubdom. I wrote it off as either (1)
MiniOS startup was so much faster than Linux that QEMU-traditional
always won the race, or (2) there was some implicit mechanism in
QEMU-traditional that ensured the HVM guest would wait for the device
model to be in place. It sounds like maybe the race ctually is being
lost in 4.5.
If the problem you are contending with is that the HVM guest is being
unpaused before the device model is in place, I suggest that this
patch, or someting much like it, should address it. I note that I
merely verified it did not break QEMU-traditional stubdom, but it is
just a matter of ensuring QEMU-traditional writes to _some_ xenstore
path when it is ready (it might do this already, in fact), and that
this patch waits on that path. Also, it should be pretty easy to
extend this concept to ensure any additional stubdoms, such as vTPM,
are up and running before leaving the code im libxl_dm.c and unpausing
the HVM domain - we just chain through additional callbacks as needed.
There may be a desire to do a major rework of libxl_dm.c, etc., but
this patch might be a reasonable bandaid now for Xen 4.5.1.
> Also upstream QEMU stubdom, as you already notice, doesn't have a
> critical functionality -- save / restore. Adding that in might involve
> upstreaming some changes to QEMU, which has a time frame that is out of
> our control.
Xen maintains a separate repo for the QEMU code it uses. I presume
this is because there is always something a little out of sync with
the mainstream QEMU release. I do not understand why we cannot rely
on this to make available any needed changes to QEMU pending their
incorporation into QEMU proper.
> So my hunch is that we're not going to make it in time for
> 4.6. :-/
>
> Wei.
4.5 was _just_ released, and Xen is on a ~10 month release cycle. Why
can't this get done? Someone just has to take a little time to sit
down and think about this. I remain baffled why Xen did not
transition to QEMU-upstream stubdom 2 years ago. Running the device
model directly in Dom0 is an obvious and significant security concern
- the QEMU codebase is in constant flux, is too big, and is too
complex to be allowed to be part of the TCB. I do not think this, or
even chroot jailing the device model (which I understand has been done
for some Xen-based projects), meets the standards for security
demonstrated by the rest of the project.
Can we arrive at an agreement that a Linux-based QEMU-upstream stubdom
should _at least_ be a technical preview for Xen 4.6? A year ago,
George kicked around the idea that QEMU-upstream stubdom should be a
blocker for Xen 4.5 - clearly this notion fell through the cracks.
For a reasonable number of users, specifically those wishing to use
Xen as a desktop solution, save/restore is not required, and could be
omitted in 4.6. I understand that rumpkernel has been a preferred
route, but realistically that looks like a Xen 5.0 feature - I have
seen no indication we are anywhere near making that happen, whereas
Linux will work now, with very few technical hurdles to overcome
(right now, the main issues seem to be getting xenfb hooked up
correctly, and deciding how we wish to handle certain elements of the
build process).
Best,
Eric
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 7/7] libxl: Wait for QEMU startup in stubdomain
2015-02-06 13:56 ` Eric Shelton
@ 2015-02-06 14:59 ` Wei Liu
2015-02-06 15:36 ` Stefano Stabellini
2015-02-06 15:46 ` Eric Shelton
0 siblings, 2 replies; 43+ messages in thread
From: Wei Liu @ 2015-02-06 14:59 UTC (permalink / raw)
To: Eric Shelton
Cc: Anthony PERARD, xen-devel, Wei Liu, Ian Campbell, Stefano Stabellini
On Fri, Feb 06, 2015 at 08:56:40AM -0500, Eric Shelton wrote:
> On Fri, Feb 6, 2015 at 6:16 AM, Wei Liu <wei.liu2@citrix.com> wrote:
> > Thanks for posting.
> >
> > ...
> >
> > FWIW we are now experiencing problem with this startup protocol (not
> > Linux stubdom specific) -- that path that libxl waiting for is wrong.
>
> I simply used the code already present in the QEMU upstream code,
> which is writing to that particular ath to indicate "running." Since
> it is distinct from the path used by the QEMU instance running in
> Dom0, it works for my intended purpose: ensuring the device model is
> running before unpausing the HVM guest. When you say it is "wrong,"
> is that just because you ultimately intend to rearchitect this and use
> something different? If so, maybe the path I am using is "good
> enough" until that happens. Otherwise, can you suggest a better path
> or mechanism?
>
It is not "good enough". It just happens to be working.
Currently the path is hardcoded "/local/domain/0/BLAH". It's wrong,
because the QEMU in stubdom is not running in 0. The correct prefix
should be "/local/domain/$stubdom_id".
Consider there is another QEMU process that runs in Dom0 that provides
some kind of backend directly to the guest, it will also write to the
same "/local/domain/0/BLAH" address. This gives us a situation that both
QEMU in stubdom and QEMU in Dom0 write to the same xenstore path, which
is of course wrong.
We would still rely on xenstore as basic mechanism to present device
model state, but the protocol as-is is broken. Since this is broken
anyway we might as well consider redesigning that protocol to make it
work both properly and future proof.
> > Unfortunately this problem can't be solved without putting in
> > significant effort and time (involves redesign of protocol and handle
> > all the compatibility issues). We can't say for sure when the solution
> > is going to land.
>
> I noticed some discussion about this on xen-devel. Unfortunately, I
> was unable to find anything that laid out specifically what the
> problems are - can you point me to a bug report or such? The libxl
> startup code - with callbacks on top of callbacks, callbacks within
> callbacks, and callbacks stashed away in little places only to be
> called _much_ later - is really convoluted, I suspect particularly so
> for stubdom startup. I am not surprised it got broken - who can
> remember how it works?
>
It's not how libxl is coded. It's the startup protocol that is broken.
The breakage of stubdom in Xen 4.5 is a latent bug exposed by a new
feature.
I guess I should just send a bug report saying "Device model startup
protocol is broken". But I don't have much to say at this point, because
thorough research for both qemu-trad and qemu-upstream is required to
produce a sensible report.
> While working on these patches reviving Anthony's work, I consistently
> ran into HVM starup problems with QEMU upstream in a stub domain (it
> always failed). What I could not figure out is why QEMU-traditional
> did not have a similar problem; it seemed to me that the same race
> existed for QEMU-traditional stubdom. I wrote it off as either (1)
> MiniOS startup was so much faster than Linux that QEMU-traditional
> always won the race, or (2) there was some implicit mechanism in
My bet is on 1).
> QEMU-traditional that ensured the HVM guest would wait for the device
> model to be in place. It sounds like maybe the race ctually is being
QEMU-trad stubdom is suffering from the same problem.
> lost in 4.5.
>
So prior to 4.5, when there is emulation request issued by a guest vcpu,
that request is put on a ring, guest vcpu is paused. When a DM shows up
it processes that request, posts response, then guest vcpu is unpaused.
So there is implicit dependency on Xen's behaviour for DM to work.
In 4.5, a new feature called ioreq server is added. When Xen sees an
io request which no backing DM, it returns immediately. Guest sees some
wired value and crashes. That is, Xen's behaviour has changed and a
latent bug in stubdom's startup protocol is exposed.
> If the problem you are contending with is that the HVM guest is being
> unpaused before the device model is in place, I suggest that this
> patch, or someting much like it, should address it. I note that I
> merely verified it did not break QEMU-traditional stubdom, but it is
> just a matter of ensuring QEMU-traditional writes to _some_ xenstore
> path when it is ready (it might do this already, in fact), and that
> this patch waits on that path. Also, it should be pretty easy to
> extend this concept to ensure any additional stubdoms, such as vTPM,
> are up and running before leaving the code im libxl_dm.c and unpausing
> the HVM domain - we just chain through additional callbacks as needed.
>
Yes, that's the basic idea, chaining things together.
> There may be a desire to do a major rework of libxl_dm.c, etc., but
> this patch might be a reasonable bandaid now for Xen 4.5.1.
>
> > Also upstream QEMU stubdom, as you already notice, doesn't have a
> > critical functionality -- save / restore. Adding that in might involve
> > upstreaming some changes to QEMU, which has a time frame that is out of
> > our control.
>
> Xen maintains a separate repo for the QEMU code it uses. I presume
> this is because there is always something a little out of sync with
> the mainstream QEMU release. I do not understand why we cannot rely
> on this to make available any needed changes to QEMU pending their
> incorporation into QEMU proper.
ISTR our policy is upstream first. That is, though we maintain our own
qemu tree those changesets are all upstream changesets. Arguably there
might be some bandaid changesets that are not upstream but big changes
like this needs to be upstreamed first.
Stefano, could you clarify this and correct me if I'm wrong?
>
> > So my hunch is that we're not going to make it in time for
> > 4.6. :-/
> >
> > Wei.
>
> 4.5 was _just_ released, and Xen is on a ~10 month release cycle. Why
> can't this get done? Someone just has to take a little time to sit
Notably there are many months that are code freeze.
And due to our upstream first QEMU policy we would also need to upstream
changes to QEMU.
> down and think about this. I remain baffled why Xen did not
> transition to QEMU-upstream stubdom 2 years ago. Running the device
> model directly in Dom0 is an obvious and significant security concern
> - the QEMU codebase is in constant flux, is too big, and is too
> complex to be allowed to be part of the TCB. I do not think this, or
> even chroot jailing the device model (which I understand has been done
> for some Xen-based projects), meets the standards for security
> demonstrated by the rest of the project.
>
I would like to have upstream QEMU as much as you do. :-)
I don't object to Linux-based stubdom (if it works, why not); however I
object to the idea that we continue to use the broken protocol. I shall
find time to kick off a discussion on xen-devel with regard to the new
protocol.
> Can we arrive at an agreement that a Linux-based QEMU-upstream stubdom
> should _at least_ be a technical preview for Xen 4.6? A year ago,
If we really want to make this happen before new protocol and
implementation are in place. That would be "tech preview" or
"experimental", whichever is the term for least mature technology. Note
that this is not due to the route it chooses (Linux based), it's due to
the fact that the protocol is broken and destined to be changed.
Wei.
> George kicked around the idea that QEMU-upstream stubdom should be a
> blocker for Xen 4.5 - clearly this notion fell through the cracks.
> For a reasonable number of users, specifically those wishing to use
> Xen as a desktop solution, save/restore is not required, and could be
> omitted in 4.6. I understand that rumpkernel has been a preferred
> route, but realistically that looks like a Xen 5.0 feature - I have
> seen no indication we are anywhere near making that happen, whereas
> Linux will work now, with very few technical hurdles to overcome
> (right now, the main issues seem to be getting xenfb hooked up
> correctly, and deciding how we wish to handle certain elements of the
> build process).
>
> Best,
> Eric
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 7/7] libxl: Wait for QEMU startup in stubdomain
2015-02-06 14:59 ` Wei Liu
@ 2015-02-06 15:36 ` Stefano Stabellini
2015-02-06 17:10 ` Eric Shelton
2015-02-06 15:46 ` Eric Shelton
1 sibling, 1 reply; 43+ messages in thread
From: Stefano Stabellini @ 2015-02-06 15:36 UTC (permalink / raw)
To: Wei Liu
Cc: Anthony PERARD, xen-devel, Ian Campbell, Stefano Stabellini,
Eric Shelton
On Fri, 6 Feb 2015, Wei Liu wrote:
> > > Unfortunately this problem can't be solved without putting in
> > > significant effort and time (involves redesign of protocol and handle
> > > all the compatibility issues). We can't say for sure when the solution
> > > is going to land.
> >
> > I noticed some discussion about this on xen-devel. Unfortunately, I
> > was unable to find anything that laid out specifically what the
> > problems are - can you point me to a bug report or such? The libxl
> > startup code - with callbacks on top of callbacks, callbacks within
> > callbacks, and callbacks stashed away in little places only to be
> > called _much_ later - is really convoluted, I suspect particularly so
> > for stubdom startup. I am not surprised it got broken - who can
> > remember how it works?
> >
>
> It's not how libxl is coded. It's the startup protocol that is broken.
> The breakage of stubdom in Xen 4.5 is a latent bug exposed by a new
> feature.
>
> I guess I should just send a bug report saying "Device model startup
> protocol is broken". But I don't have much to say at this point, because
> thorough research for both qemu-trad and qemu-upstream is required to
> produce a sensible report.
>
> > While working on these patches reviving Anthony's work, I consistently
> > ran into HVM starup problems with QEMU upstream in a stub domain (it
> > always failed). What I could not figure out is why QEMU-traditional
> > did not have a similar problem; it seemed to me that the same race
> > existed for QEMU-traditional stubdom. I wrote it off as either (1)
> > MiniOS startup was so much faster than Linux that QEMU-traditional
> > always won the race, or (2) there was some implicit mechanism in
>
> My bet is on 1).
>
> > QEMU-traditional that ensured the HVM guest would wait for the device
> > model to be in place. It sounds like maybe the race ctually is being
>
> QEMU-trad stubdom is suffering from the same problem.
>
> > lost in 4.5.
> >
>
> So prior to 4.5, when there is emulation request issued by a guest vcpu,
> that request is put on a ring, guest vcpu is paused. When a DM shows up
> it processes that request, posts response, then guest vcpu is unpaused.
> So there is implicit dependency on Xen's behaviour for DM to work.
>
> In 4.5, a new feature called ioreq server is added. When Xen sees an
> io request which no backing DM, it returns immediately. Guest sees some
> wired value and crashes. That is, Xen's behaviour has changed and a
> latent bug in stubdom's startup protocol is exposed.
I don't think we can stall the development of a new feature like this
based on what can be seen as a regression.
If the bug cannot be fixed in a timely fashion we should revert to
previous behaviour as soon as possible.
> > If the problem you are contending with is that the HVM guest is being
> > unpaused before the device model is in place, I suggest that this
> > patch, or someting much like it, should address it. I note that I
> > merely verified it did not break QEMU-traditional stubdom, but it is
> > just a matter of ensuring QEMU-traditional writes to _some_ xenstore
> > path when it is ready (it might do this already, in fact), and that
> > this patch waits on that path. Also, it should be pretty easy to
> > extend this concept to ensure any additional stubdoms, such as vTPM,
> > are up and running before leaving the code im libxl_dm.c and unpausing
> > the HVM domain - we just chain through additional callbacks as needed.
> >
>
> Yes, that's the basic idea, chaining things together.
>
> > There may be a desire to do a major rework of libxl_dm.c, etc., but
> > this patch might be a reasonable bandaid now for Xen 4.5.1.
> >
> > > Also upstream QEMU stubdom, as you already notice, doesn't have a
> > > critical functionality -- save / restore. Adding that in might involve
> > > upstreaming some changes to QEMU, which has a time frame that is out of
> > > our control.
> >
> > Xen maintains a separate repo for the QEMU code it uses. I presume
> > this is because there is always something a little out of sync with
> > the mainstream QEMU release. I do not understand why we cannot rely
> > on this to make available any needed changes to QEMU pending their
> > incorporation into QEMU proper.
>
> ISTR our policy is upstream first. That is, though we maintain our own
> qemu tree those changesets are all upstream changesets. Arguably there
> might be some bandaid changesets that are not upstream but big changes
> like this needs to be upstreamed first.
>
> Stefano, could you clarify this and correct me if I'm wrong?
Yes, the policy is upstream first, however it doesn't need to land in a
QEMU release. Just be upstream.
There is still please of time for that: Eric just needs to send his
patches to qemu-devel, get the acks, and I'll apply to
qemu-xen-upstream.
> > > So my hunch is that we're not going to make it in time for
> > > 4.6. :-/
> > >
> > > Wei.
> >
> > 4.5 was _just_ released, and Xen is on a ~10 month release cycle. Why
> > can't this get done? Someone just has to take a little time to sit
>
> Notably there are many months that are code freeze.
>
> And due to our upstream first QEMU policy we would also need to upstream
> changes to QEMU.
Getting the patches upstream in QEMU shouldn't take longer than getting
them upstream in Xen.
Also I think upstream QEMU stubdoms would be valuable even without
save/restore support.
> > Can we arrive at an agreement that a Linux-based QEMU-upstream stubdom
> > should _at least_ be a technical preview for Xen 4.6? A year ago,
I agree. Or rumpkernel-based QEMU-upstream stubdom. Or something.
> If we really want to make this happen before new protocol and
> implementation are in place. That would be "tech preview" or
> "experimental", whichever is the term for least mature technology. Note
> that this is not due to the route it chooses (Linux based), it's due to
> the fact that the protocol is broken and destined to be changed.
I think we should not block the entire upstream stubdom effort, whether
it is Linux, MiniOS or Rumpkernel based, waiting for the bootup protocol
to be fixed.
The two things can and should be done in parallel.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 0/7] RFC Linux-based QEMU-upstream stub domain
2015-02-04 4:06 [RFC 0/7] RFC Linux-based QEMU-upstream stub domain Eric Shelton
` (6 preceding siblings ...)
2015-02-04 4:06 ` [RFC 7/7] libxl: Wait for QEMU startup in stubdomain Eric Shelton
@ 2015-02-06 15:42 ` Stefano Stabellini
7 siblings, 0 replies; 43+ messages in thread
From: Stefano Stabellini @ 2015-02-06 15:42 UTC (permalink / raw)
To: Eric Shelton; +Cc: anthony.perard, xen-devel, Ian.Campbell, stefano.stabellini
On Tue, 3 Feb 2015, Eric Shelton wrote:
> This patch series updates Anthony Perard's original patch series to
> bring support for running QEMU upstream as a device model in a
> stubdomain by using a Linux-based stubdom, rather than MiniOS as
> currently used for QEMU traditional. Anthony posted the original
> patch series on April 17, 2013.
>
> The first three patches build Linux 3.17.8 and a disk image for the
> stubdomain itself. QEMU is being pulled from the same repo as is
> being used for Xen 4.5.0, and some minor patches are being applied.
> A new directory is created within xen.git, stubdom-linux. Calling
> 'make' in this directory will build Linux, QEMU upstream, and an
> ext2 disk image. Then a 'make install' will copy the Linux kernel
> and disk image into the same directory used for other stubdomain
> images, such as MiniOS. This build process has by no means been
> integrated with the overall Xen build process. A more refined
> process would be expected for release code, such as integration
> with configure, eliminating the hard-coded path for 'make install',
> and only doing a single download of the QEMU sources.
>
> The last four patches are the libxl support, which allows selecting
> between MiniOS/QEMU-traditional and Linux/QEMU-upstream. For
> QEMU-upstream, the VM config file would include:
>
> device_model_version = "qemu-xen"
> device_model_stubdomain_override = 1
>
> For QEMU-traditional, the VM config file would include:
>
> device_model_version = "qemu-xen-traditional"
> device_model_stubdomain_override = 1
>
> There a number of features that are not supported yet:
> - video output (e.g., VNC)
> - save/restore
> - QMP
>
> QMP, or at least part of the QMP protocol, will likely present
> some interesting issues. Assumedly, there will be some subset of
> QMP commands that will require some coordination between the QEMU
> instance running in the stubdomain and a QEMU instance running in
> Dom0 (or some other domain).
I guess QMP could be routed via a PV console.
> Other expected tweaks:
> - Currently 128MB of memory is being used for the stubdomain. This
> is more than needed, but no attempt has been made to find the
> appropriate lower limit.
> - The kernel config.
> - The disk image can be made smaller.
>
> This patch series has been successfully used to run a simple Linux
> HVM guest, without the Xen drivers built into the kernel (this is
> not meant to imply that the drivers will not work, but was more to
> confirm the emulated NIC and disks provided by QEMU worked). Once
> booted up, it was possible to successfully SSH into the Linux HVM
> guest.
>
> Regards,
> Eric Shelton
>
> --
>
> Patches:
> [RFC 1/7] linux-stubdomain: Compile QEMU
> [RFC 2/7] linux-stubdomain: Compile Linux
> [RFC 3/7] linux-stubdomain: Build a disk image
> [RFC 4/7] libxl: Add "stubdomain_version" to domain_build_info
> [RFC 5/7] libxl: Handle Linux stubdomain specific QEMU options
> [RFC 6/7] libxl: Build the domain with a Linux based stubdomain
> [RFC 7/7] libxl: Wait for QEMU startup in stubdomain
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 7/7] libxl: Wait for QEMU startup in stubdomain
2015-02-06 14:59 ` Wei Liu
2015-02-06 15:36 ` Stefano Stabellini
@ 2015-02-06 15:46 ` Eric Shelton
2015-02-06 16:12 ` Wei Liu
1 sibling, 1 reply; 43+ messages in thread
From: Eric Shelton @ 2015-02-06 15:46 UTC (permalink / raw)
To: Wei Liu; +Cc: Anthony PERARD, xen-devel, Ian Campbell, Stefano Stabellini
On Fri, Feb 6, 2015 at 9:59 AM, Wei Liu <wei.liu2@citrix.com> wrote:
> On Fri, Feb 06, 2015 at 08:56:40AM -0500, Eric Shelton wrote:
>> On Fri, Feb 6, 2015 at 6:16 AM, Wei Liu <wei.liu2@citrix.com> wrote:
>>
>> I simply used the code already present in the QEMU upstream code,
>> which is writing to that particular ath to indicate "running." Since
>> it is distinct from the path used by the QEMU instance running in
>> Dom0, it works for my intended purpose: ensuring the device model is
>> running before unpausing the HVM guest. When you say it is "wrong,"
>> is that just because you ultimately intend to rearchitect this and use
>> something different? If so, maybe the path I am using is "good
>> enough" until that happens. Otherwise, can you suggest a better path
>> or mechanism?
>>
>
> It is not "good enough". It just happens to be working.
>
> Currently the path is hardcoded "/local/domain/0/BLAH". It's wrong,
> because the QEMU in stubdom is not running in 0. The correct prefix
> should be "/local/domain/$stubdom_id".
OK; that definitely makes more sense - I recall the same idea crossing
my mind when I first dug into this. Although the revised protocol may
go in a different direction, I will adopt this approach for now.
>> I noticed some discussion about this on xen-devel. Unfortunately, I
>> was unable to find anything that laid out specifically what the
>> problems are - can you point me to a bug report or such? The libxl
>> startup code - with callbacks on top of callbacks, callbacks within
>> callbacks, and callbacks stashed away in little places only to be
>> called _much_ later - is really convoluted, I suspect particularly so
>> for stubdom startup. I am not surprised it got broken - who can
>> remember how it works?
>>
>
> It's not how libxl is coded. It's the startup protocol that is broken.
> The breakage of stubdom in Xen 4.5 is a latent bug exposed by a new
> feature.
>
> I guess I should just send a bug report saying "Device model startup
> protocol is broken". But I don't have much to say at this point, because
> thorough research for both qemu-trad and qemu-upstream is required to
> produce a sensible report.
So, just where is the current protocol breaking down? Is there a
contemplated bandaid for 4.5.1? I'm just trying to figure out what I
might want to do differently.
> So prior to 4.5, when there is emulation request issued by a guest vcpu,
> that request is put on a ring, guest vcpu is paused. When a DM shows up
> it processes that request, posts response, then guest vcpu is unpaused.
> So there is implicit dependency on Xen's behaviour for DM to work.
>
> In 4.5, a new feature called ioreq server is added. When Xen sees an
> io request which no backing DM, it returns immediately. Guest sees some
> wired value and crashes. That is, Xen's behaviour has changed and a
> latent bug in stubdom's startup protocol is exposed.
So, is the approach that I took - waiting for the stubdom DM to finish
initializing - a reasonable short-term solution? I guess I am
wondering whether the fix you are contemplating is in libxl, the
hypervisor, or both.
Thanks,
Eric
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 1/7] linux-stubdomain: Compile QEMU
2015-02-04 4:06 ` [RFC 1/7] linux-stubdomain: Compile QEMU Eric Shelton
@ 2015-02-06 15:46 ` Stefano Stabellini
2015-02-06 17:25 ` Eric Shelton
0 siblings, 1 reply; 43+ messages in thread
From: Stefano Stabellini @ 2015-02-06 15:46 UTC (permalink / raw)
To: Eric Shelton; +Cc: anthony.perard, xen-devel, Ian.Campbell, stefano.stabellini
On Tue, 3 Feb 2015, Eric Shelton wrote:
> This patch adds a Makefile which downloads, patches, and compiles
> upstream QEMU for a stubdomain based on a linux kernel.
>
> Signed-off-by: Eric Shelton <eshelton@pobox.com>
> ---
> stubdom-linux/.gitignore | 3 ++
> stubdom-linux/Makefile | 55 +++++++++++++++++++++++++++++++++++++
> stubdom-linux/qemu-configure.patch | 47 +++++++++++++++++++++++++++++++
> stubdom-linux/qemu-xen-common.patch | 12 ++++++++
> stubdom-linux/qemu-xen-h.patch | 18 ++++++++++++
> stubdom-linux/qemu-xen-hvm.patch | 36 ++++++++++++++++++++++++
> 6 files changed, 171 insertions(+)
> create mode 100644 stubdom-linux/.gitignore
> create mode 100644 stubdom-linux/Makefile
> create mode 100644 stubdom-linux/qemu-configure.patch
> create mode 100644 stubdom-linux/qemu-xen-common.patch
> create mode 100644 stubdom-linux/qemu-xen-h.patch
> create mode 100644 stubdom-linux/qemu-xen-hvm.patch
>
> diff --git a/stubdom-linux/.gitignore b/stubdom-linux/.gitignore
> new file mode 100644
> index 0000000..1b5ec08
> --- /dev/null
> +++ b/stubdom-linux/.gitignore
> @@ -0,0 +1,3 @@
> +/qemu-build/
> +/qemu-remote
> +/qemu-remote-remote/
> diff --git a/stubdom-linux/Makefile b/stubdom-linux/Makefile
> new file mode 100644
> index 0000000..4e84a61
> --- /dev/null
> +++ b/stubdom-linux/Makefile
> @@ -0,0 +1,55 @@
> +XEN_ROOT = $(CURDIR)/..
> +
> +-include $(XEN_ROOT)/config/Tools.mk
> +include $(XEN_ROOT)/Config.mk
> +
> +# Qemu tree used
> +QEMU_TREE=git://xenbits.xen.org/qemu-upstream-4.5-testing.git
> +QEMU_BRANCH=qemu-xen-4.5.0
> +
> +all:
> +
> +qemu-build/Makefile:
> + export GIT=$(GIT); \
> + $(XEN_ROOT)/scripts/git-checkout.sh $(QEMU_TREE) $(QEMU_BRANCH) qemu-remote
> + cd qemu-remote && patch -p1 < ../qemu-configure.patch
> + cd qemu-remote && patch -p1 < ../qemu-xen-common.patch
> + cd qemu-remote && patch -p1 < ../qemu-xen-h.patch
> + cd qemu-remote && patch -p1 < ../qemu-xen-hvm.patch
Before having patches, I would like to try to get them upstream in QEMU.
If we really cannot do that, then I would still prefer to commit any
required workarounds to the qemu-xen rather than having them here as
patches.
> + mkdir -p qemu-build
> + cd qemu-build && ../qemu-remote/configure \
> + --target-list=i386-softmmu \
> + --enable-xen \
> + --extra-cflags="-I$(XEN_ROOT)/tools/include \
> + -I$(XEN_ROOT)/tools/libxc \
> + -I$(XEN_ROOT)/tools/xenstore \
> + -I$(XEN_ROOT)/tools/xenstore/compat \
> + -DDEBUG_XEN" \
> + --extra-ldflags="-L$(XEN_ROOT)/tools/libxc -L$(XEN_ROOT)/tools/xenstore" \
> + --disable-werror \
> + --disable-sdl \
> + --disable-kvm \
> + --disable-gtk \
> + --disable-fdt \
> + --disable-bluez \
> + --disable-libusb \
> + --disable-slirp \
> + --disable-pie \
> + --disable-docs \
> + --disable-vhost-net \
> + --disable-spice \
> + --disable-guest-agent \
> + --audio-drv-list= \
> + --disable-smartcard-nss \
> + --enable-stubdom \
> + --disable-vnc \
> + --disable-spice \
> + --enable-trace-backend=stderr \
> + --disable-curses \
> + --python=$(PYTHON) \
> + --prefix=
> +
> +.PHONY:qemu-build
> +qemu-build: qemu-build/Makefile
> +qemu-build/i386-softmmu/qemu-system-i386: qemu-build
> + $(MAKE) -C qemu-build
> diff --git a/stubdom-linux/qemu-configure.patch b/stubdom-linux/qemu-configure.patch
> new file mode 100644
> index 0000000..b93132d
> --- /dev/null
> +++ b/stubdom-linux/qemu-configure.patch
> @@ -0,0 +1,47 @@
> +--- a/configure 2015-01-21 23:48:23.763333326 -0500
> ++++ b/configure 2015-01-21 23:52:30.326666664 -0500
> +@@ -300,6 +300,7 @@
> + libusb=""
> + usb_redir=""
> + glx=""
> ++stubdom="no"
> + zlib="yes"
> + lzo="no"
> + snappy="no"
> +@@ -1021,6 +1022,8 @@
> + ;;
> + --enable-usb-redir) usb_redir="yes"
> + ;;
> ++ --enable-stubdom) stubdom="yes"
> ++ ;;
> + --disable-zlib-test) zlib="no"
> + ;;
> + --enable-lzo) lzo="yes"
> +@@ -1329,6 +1332,7 @@
> + --enable-usb-redir enable usb network redirection support
> + --enable-lzo enable the support of lzo compression library
> + --enable-snappy enable the support of snappy compression library
> ++ --enable-stubdom enable building the ioemu-stubdom
> + --disable-guest-agent disable building of the QEMU Guest Agent
> + --enable-guest-agent enable building of the QEMU Guest Agent
> + --with-vss-sdk=SDK-path enable Windows VSS support in QEMU Guest Agent
> +@@ -4122,6 +4126,7 @@
> + echo "Target Sparc Arch $sparc_cpu"
> + fi
> + echo "xen support $xen"
> ++echo "stubdom support $stubdom"
> + echo "brlapi support $brlapi"
> + echo "bluez support $bluez"
> + echo "Documentation $docs"
> +@@ -4553,6 +4558,11 @@
> + echo "RBD_LIBS=$rbd_libs" >> $config_host_mak
> + fi
> +
> ++# stubdom support
> ++if test "$stubdom" = "yes"; then
> ++ echo "CONFIG_STUBDOM=y" >> $config_host_mak
> ++fi
> ++
> + echo "CONFIG_COROUTINE_BACKEND=$coroutine" >> $config_host_mak
> + if test "$coroutine_pool" = "yes" ; then
> + echo "CONFIG_COROUTINE_POOL=1" >> $config_host_mak
> diff --git a/stubdom-linux/qemu-xen-common.patch b/stubdom-linux/qemu-xen-common.patch
> new file mode 100644
> index 0000000..b473e36
> --- /dev/null
> +++ b/stubdom-linux/qemu-xen-common.patch
> @@ -0,0 +1,12 @@
> +--- a/xen-common.c 2015-01-25 20:42:36.329999998 -0500
> ++++ b/xen-common.c 2015-01-25 20:43:20.346666663 -0500
> +@@ -92,7 +92,8 @@
> + exit(1);
> + }
> +
> +- snprintf(path, sizeof (path), "device-model/%u/state", xen_domid);
> ++ snprintf(path, sizeof (path),
> ++ "/local/domain/0/device-model/%u/state", xen_domid);
Even if this counts as a workaround, I think it could go upstream in
QEMU.
> + if (!xs_write(xs, XBT_NULL, path, state, strlen(state))) {
> + fprintf(stderr, "error recording dm state\n");
> + exit(1);
> diff --git a/stubdom-linux/qemu-xen-h.patch b/stubdom-linux/qemu-xen-h.patch
> new file mode 100644
> index 0000000..262b1d1
> --- /dev/null
> +++ b/stubdom-linux/qemu-xen-h.patch
> @@ -0,0 +1,18 @@
> +--- a/include/hw/xen/xen.h 2015-01-21 23:54:36.856666662 -0500
> ++++ b/include/hw/xen/xen.h 2015-01-21 23:55:39.356666667 -0500
> +@@ -28,6 +28,15 @@
> + return xen_allowed;
> + }
> +
> ++static inline int xen_stubdom_enable(void)
> ++{
> ++#ifdef CONFIG_STUBDOM
> ++ return 1;
> ++#else
> ++ return 0;
> ++#endif
> ++}
As the STUBDOM related changes are small, I think we could avoid to
introduce this config option altogether.
Maybe we could figure out that we are running as stubdom with a runtime
option, like a command line argument, something on xenstore or even our
own domain id.
> + int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num);
> + void xen_piix3_set_irq(void *opaque, int irq_num, int level);
> + void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len);
> diff --git a/stubdom-linux/qemu-xen-hvm.patch b/stubdom-linux/qemu-xen-hvm.patch
> new file mode 100644
> index 0000000..ac6a53f
> --- /dev/null
> +++ b/stubdom-linux/qemu-xen-hvm.patch
> @@ -0,0 +1,36 @@
> +--- a/xen-hvm.c 2015-01-21 22:32:42.999999995 -0500
> ++++ b/xen-hvm.c 2015-01-21 22:35:17.633333330 -0500
> +@@ -1008,6 +1008,10 @@
> + state->wakeup.notify = xen_wakeup_notifier;
> + qemu_register_wakeup_notifier(&state->wakeup);
> +
> ++ if (xen_stubdom_enable()) {
> ++ xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_DM_DOMAIN, DOMID_SELF);
> ++ }
> ++
> + xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_IOREQ_PFN, &ioreq_pfn);
> + DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
> + state->shared_page = xc_map_foreign_range(xen_xc, xen_domid, XC_PAGE_SIZE,
> +@@ -1063,6 +1067,7 @@
> + memory_listener_register(&state->memory_listener, &address_space_memory);
> + state->log_for_dirtybit = NULL;
> +
> ++#ifndef CONFIG_STUBDOM
> + /* Initialize backend core & drivers */
> + if (xen_be_init() != 0) {
> + fprintf(stderr, "%s: xen backend core setup failed\n", __FUNCTION__);
> +@@ -1071,6 +1076,14 @@
> + xen_be_register("console", &xen_console_ops);
> + xen_be_register("vkbd", &xen_kbdmouse_ops);
> + xen_be_register("qdisk", &xen_blkdev_ops);
> ++#else
> ++ xenstore = xs_daemon_open();
> ++ if (!xenstore) {
> ++ xen_be_printf(NULL, 0, "can't connect to xenstored\n");
> ++ return -1;
> ++ }
> ++#endif
> ++
> + xen_read_physmap(state);
> +
> + return 0;
> --
> 1.8.5.5
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 2/7] linux-stubdomain: Compile Linux
2015-02-04 4:06 ` [RFC 2/7] linux-stubdomain: Compile Linux Eric Shelton
@ 2015-02-06 15:51 ` Stefano Stabellini
2015-02-06 17:42 ` Eric Shelton
0 siblings, 1 reply; 43+ messages in thread
From: Stefano Stabellini @ 2015-02-06 15:51 UTC (permalink / raw)
To: Eric Shelton; +Cc: anthony.perard, xen-devel, Ian.Campbell, stefano.stabellini
On Tue, 3 Feb 2015, Eric Shelton wrote:
> This patch adds rules to the Makefile to retrieve Linux and build a
> minimal kernel for the stubdomain. Using Linux kernel 3.17.8.
>
> In order to work as a stubdomain, two patches are applied to the Linux
> kernel source.
Similarly to QEMU, we should get the changes upstream in Linux.
Failing that we could use a Linux tree on xenbits instead of a stable
kernel release and apply and needed workarounds there.
> Signed-off-by: Eric Shelton <eshelton@pobox.com>
> ---
> stubdom-linux/.gitignore | 3 +
> ...-Don-t-write-in-the-type-node-in-xenstore.patch | 30 +
> stubdom-linux/0002-fix-remap_area_mfn_pte_fn.patch | 38 +
> stubdom-linux/Makefile | 24 +-
> stubdom-linux/stubdom-linux-config-64b | 1510 ++++++++++++++++++++
> 5 files changed, 1604 insertions(+), 1 deletion(-)
> create mode 100644 stubdom-linux/0001-hvc_xen-Don-t-write-in-the-type-node-in-xenstore.patch
> create mode 100644 stubdom-linux/0002-fix-remap_area_mfn_pte_fn.patch
> create mode 100644 stubdom-linux/stubdom-linux-config-64b
>
> diff --git a/stubdom-linux/.gitignore b/stubdom-linux/.gitignore
> index 1b5ec08..891f0c8 100644
> --- a/stubdom-linux/.gitignore
> +++ b/stubdom-linux/.gitignore
> @@ -1,3 +1,6 @@
> /qemu-build/
> /qemu-remote
> /qemu-remote-remote/
> +/linux-*.tar.xz
> +/linux-*/
> +/vmlinuz-stubdom
> diff --git a/stubdom-linux/0001-hvc_xen-Don-t-write-in-the-type-node-in-xenstore.patch b/stubdom-linux/0001-hvc_xen-Don-t-write-in-the-type-node-in-xenstore.patch
> new file mode 100644
> index 0000000..24fac2f
> --- /dev/null
> +++ b/stubdom-linux/0001-hvc_xen-Don-t-write-in-the-type-node-in-xenstore.patch
> @@ -0,0 +1,30 @@
> +From bc93f3b6d97b1376a5f5d1dbb746d82f8003e184 Mon Sep 17 00:00:00 2001
> +From: Anthony PERARD <anthony.perard@citrix.com>
> +Date: Tue, 20 Aug 2013 17:07:53 +0100
> +Subject: [PATCH] hvc_xen: Don't write in the type node in xenstore.
> +
> +Due to a recent commit in the Xen Project, writing to "type" is not
> +allowed any more.
> +
> +Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> +---
> + drivers/tty/hvc/hvc_xen.c | 3 ---
> + 1 file changed, 3 deletions(-)
> +
> +diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> +index 682210d..032add4 100644
> +--- a/drivers/tty/hvc/hvc_xen.c
> ++++ b/drivers/tty/hvc/hvc_xen.c
> +@@ -402,9 +402,6 @@ static int xencons_connect_backend(struct xenbus_device *dev,
> + evtchn);
> + if (ret)
> + goto error_xenbus;
> +- ret = xenbus_printf(xbt, dev->nodename, "type", "ioemu");
> +- if (ret)
> +- goto error_xenbus;
> + ret = xenbus_transaction_end(xbt, 0);
> + if (ret) {
> + if (ret == -EAGAIN)
I think that this is already upstream
> +Anthony PERARD
> +
> diff --git a/stubdom-linux/0002-fix-remap_area_mfn_pte_fn.patch b/stubdom-linux/0002-fix-remap_area_mfn_pte_fn.patch
> new file mode 100644
> index 0000000..e26b0da
> --- /dev/null
> +++ b/stubdom-linux/0002-fix-remap_area_mfn_pte_fn.patch
> @@ -0,0 +1,38 @@
> +From 61cd574f29f41046f1c709cfa9da118156babf83 Mon Sep 17 00:00:00 2001
> +From: Anthony PERARD <anthony.perard@citrix.com>
> +Date: Fri, 1 Jun 2012 15:47:01 +0100
> +Subject: [PATCH 2/2] fix/remap_area_mfn_pte_fn
> +
> +---
> + arch/x86/xen/mmu.c | 13 ++++++++++++-
> + 1 file changed, 12 insertions(+), 1 deletion(-)
> +
> +diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> +index 69f5857..999fc82 100644
> +--- a/arch/x86/xen/mmu.c
> ++++ b/arch/x86/xen/mmu.c
> +@@ -2606,7 +2606,20 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
> + unsigned long addr, void *data)
> + {
> + struct remap_data *rmd = data;
> +- pte_t pte = pte_mkspecial(mfn_pte(rmd->mfn++, rmd->prot));
> ++
> ++ /* Use the native_make_pte function because we are sure we don't
> ++ * have to do any pfn->mfn translations but at the same time we
> ++ * could in a stubdom so xen_initial_domain() would return false. */
> ++ pte_t pte = pte_mkspecial(native_make_pte(((phys_addr_t)(rmd->mfn++) << PAGE_SHIFT)
> ++ | massage_pgprot(rmd->prot)));
> ++ pteval_t val = pte_val_ma(pte);
> ++
> ++#if 0
> ++ if (pat_enabled && !WARN_ON(val & _PAGE_PAT)) {
> ++ if ((val & (_PAGE_PCD | _PAGE_PWT)) == _PAGE_PWT)
> ++ val = (val & ~(_PAGE_PCD | _PAGE_PWT)) | _PAGE_PAT;
> ++ }
> ++#endif
I don't think you need this change anymore with a more recent kernel.
In any case, a proper fix for this issue would certainly be welcome
upstream in Linux.
> + rmd->mmu_update->ptr = virt_to_machine(ptep).maddr;
> + rmd->mmu_update->val = pte_val_ma(pte);
> +--
> +Anthony PERARD
> +
> diff --git a/stubdom-linux/Makefile b/stubdom-linux/Makefile
> index 4e84a61..31bfbee 100644
> --- a/stubdom-linux/Makefile
> +++ b/stubdom-linux/Makefile
> @@ -7,7 +7,12 @@ include $(XEN_ROOT)/Config.mk
> QEMU_TREE=git://xenbits.xen.org/qemu-upstream-4.5-testing.git
> QEMU_BRANCH=qemu-xen-4.5.0
>
> -all:
> +# Linux Kernel version used
> +LINUX_V=linux-3.17.8
> +VMLINUZ=$(LINUX_V)/arch/x86/boot/bzImage
> +LINUX_URL=ftp://ftp.kernel.org/pub/linux/kernel/v3.x/$(LINUX_V).tar.xz
> +
> +all: $(VMLINUZ)
I think it is best if we git clone it.
> qemu-build/Makefile:
> export GIT=$(GIT); \
> @@ -53,3 +58,20 @@ qemu-build/Makefile:
> qemu-build: qemu-build/Makefile
> qemu-build/i386-softmmu/qemu-system-i386: qemu-build
> $(MAKE) -C qemu-build
> +
> +$(LINUX_V).tar.xz:
> + $(FETCHER) $@ $(LINUX_URL)
> +
> +$(LINUX_V)/Makefile $(LINUX_V)/.config: $(LINUX_V).tar.xz
> + rm -rf $(LINUX_V)
> + tar xf $(LINUX_V).tar.xz
> + # Temp patches
> + patch -d $(LINUX_V) -p1 -i ../0002-fix-remap_area_mfn_pte_fn.patch
> + patch -d $(LINUX_V) -p1 -i ../0001-hvc_xen-Don-t-write-in-the-type-node-in-xenstore.patch
> + cp stubdom-linux-config-64b $(LINUX_V)/.config
> +
> +$(VMLINUZ): $(LINUX_V)/.config
> + $(MAKE) -C $(LINUX_V)
> +
> +install: $(VMLINUZ)
> + cp -f $(VMLINUZ) $(DESTDIR)/usr/local/lib/xen/boot/vmlinuz-stubdom
> diff --git a/stubdom-linux/stubdom-linux-config-64b b/stubdom-linux/stubdom-linux-config-64b
> new file mode 100644
> index 0000000..d69f374
> --- /dev/null
> +++ b/stubdom-linux/stubdom-linux-config-64b
> @@ -0,0 +1,1510 @@
> +#
> +# Automatically generated file; DO NOT EDIT.
> +# Linux/x86 3.17.8 Kernel Configuration
Where does it come from?
Is it the defconfig?
> +CONFIG_64BIT=y
> +CONFIG_X86_64=y
> +CONFIG_X86=y
> +CONFIG_INSTRUCTION_DECODER=y
> +CONFIG_OUTPUT_FORMAT="elf64-x86-64"
> +CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
> +CONFIG_LOCKDEP_SUPPORT=y
> +CONFIG_STACKTRACE_SUPPORT=y
> +CONFIG_HAVE_LATENCYTOP_SUPPORT=y
> +CONFIG_MMU=y
> +CONFIG_NEED_DMA_MAP_STATE=y
> +CONFIG_NEED_SG_DMA_LENGTH=y
> +CONFIG_GENERIC_ISA_DMA=y
> +CONFIG_GENERIC_BUG=y
> +CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
> +CONFIG_GENERIC_HWEIGHT=y
> +CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> +CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> +CONFIG_GENERIC_CALIBRATE_DELAY=y
> +CONFIG_ARCH_HAS_CPU_RELAX=y
> +CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> +CONFIG_HAVE_SETUP_PER_CPU_AREA=y
> +CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
> +CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
> +CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> +CONFIG_ARCH_SUSPEND_POSSIBLE=y
> +CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
> +CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
> +CONFIG_ZONE_DMA32=y
> +CONFIG_AUDIT_ARCH=y
> +CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
> +CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> +CONFIG_X86_64_SMP=y
> +CONFIG_X86_HT=y
> +CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11"
> +CONFIG_ARCH_SUPPORTS_UPROBES=y
> +CONFIG_FIX_EARLYCON_MEM=y
> +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
> +CONFIG_IRQ_WORK=y
> +CONFIG_BUILDTIME_EXTABLE_SORT=y
> +
> +#
> +# General setup
> +#
> +CONFIG_INIT_ENV_ARG_LIMIT=32
> +CONFIG_CROSS_COMPILE=""
> +# CONFIG_COMPILE_TEST is not set
> +CONFIG_LOCALVERSION="-XenStubdom"
> +# CONFIG_LOCALVERSION_AUTO is not set
> +CONFIG_HAVE_KERNEL_GZIP=y
> +CONFIG_HAVE_KERNEL_BZIP2=y
> +CONFIG_HAVE_KERNEL_LZMA=y
> +CONFIG_HAVE_KERNEL_XZ=y
> +CONFIG_HAVE_KERNEL_LZO=y
> +CONFIG_HAVE_KERNEL_LZ4=y
> +CONFIG_KERNEL_GZIP=y
> +# CONFIG_KERNEL_BZIP2 is not set
> +# CONFIG_KERNEL_LZMA is not set
> +# CONFIG_KERNEL_XZ is not set
> +# CONFIG_KERNEL_LZO is not set
> +# CONFIG_KERNEL_LZ4 is not set
> +CONFIG_DEFAULT_HOSTNAME="stubdom"
> +# CONFIG_SWAP is not set
> +# CONFIG_SYSVIPC is not set
> +# CONFIG_POSIX_MQUEUE is not set
> +# CONFIG_CROSS_MEMORY_ATTACH is not set
> +# CONFIG_FHANDLE is not set
> +CONFIG_USELIB=y
> +# CONFIG_AUDIT is not set
> +CONFIG_HAVE_ARCH_AUDITSYSCALL=y
> +
> +#
> +# IRQ subsystem
> +#
> +CONFIG_GENERIC_IRQ_PROBE=y
> +CONFIG_GENERIC_IRQ_SHOW=y
> +CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y
> +CONFIG_GENERIC_PENDING_IRQ=y
> +CONFIG_IRQ_DOMAIN=y
> +CONFIG_IRQ_FORCED_THREADING=y
> +CONFIG_SPARSE_IRQ=y
> +CONFIG_CLOCKSOURCE_WATCHDOG=y
> +CONFIG_ARCH_CLOCKSOURCE_DATA=y
> +CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
> +CONFIG_GENERIC_TIME_VSYSCALL=y
> +CONFIG_GENERIC_CLOCKEVENTS=y
> +CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
> +CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
> +CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
> +CONFIG_GENERIC_CMOS_UPDATE=y
> +
> +#
> +# Timers subsystem
> +#
> +CONFIG_TICK_ONESHOT=y
> +CONFIG_NO_HZ_COMMON=y
> +# CONFIG_HZ_PERIODIC is not set
> +CONFIG_NO_HZ_IDLE=y
> +# CONFIG_NO_HZ_FULL is not set
> +# CONFIG_NO_HZ is not set
> +# CONFIG_HIGH_RES_TIMERS is not set
> +
> +#
> +# CPU/Task time and stats accounting
> +#
> +CONFIG_VIRT_CPU_ACCOUNTING=y
> +# CONFIG_TICK_CPU_ACCOUNTING is not set
> +CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
> +# CONFIG_IRQ_TIME_ACCOUNTING is not set
> +# CONFIG_BSD_PROCESS_ACCT is not set
> +# CONFIG_TASKSTATS is not set
> +
> +#
> +# RCU Subsystem
> +#
> +CONFIG_TREE_RCU=y
> +# CONFIG_PREEMPT_RCU is not set
> +CONFIG_RCU_STALL_COMMON=y
> +CONFIG_CONTEXT_TRACKING=y
> +# CONFIG_RCU_USER_QS is not set
> +# CONFIG_CONTEXT_TRACKING_FORCE is not set
> +CONFIG_RCU_FANOUT=64
> +CONFIG_RCU_FANOUT_LEAF=16
> +# CONFIG_RCU_FANOUT_EXACT is not set
> +# CONFIG_RCU_FAST_NO_HZ is not set
> +# CONFIG_TREE_RCU_TRACE is not set
> +# CONFIG_RCU_NOCB_CPU is not set
> +# CONFIG_BUILD_BIN2C is not set
> +# CONFIG_IKCONFIG is not set
> +CONFIG_LOG_BUF_SHIFT=14
> +CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
> +CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
> +CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
> +CONFIG_ARCH_SUPPORTS_INT128=y
> +CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
> +# CONFIG_CGROUPS is not set
> +# CONFIG_CHECKPOINT_RESTORE is not set
> +# CONFIG_NAMESPACES is not set
> +# CONFIG_SCHED_AUTOGROUP is not set
> +CONFIG_SYSFS_DEPRECATED=y
> +# CONFIG_SYSFS_DEPRECATED_V2 is not set
> +# CONFIG_RELAY is not set
> +CONFIG_BLK_DEV_INITRD=y
> +CONFIG_INITRAMFS_SOURCE=""
> +CONFIG_RD_GZIP=y
> +CONFIG_RD_BZIP2=y
> +CONFIG_RD_LZMA=y
> +CONFIG_RD_XZ=y
> +CONFIG_RD_LZO=y
> +CONFIG_RD_LZ4=y
> +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
> +CONFIG_ANON_INODES=y
> +CONFIG_SYSCTL_EXCEPTION_TRACE=y
> +CONFIG_HAVE_PCSPKR_PLATFORM=y
> +CONFIG_EXPERT=y
> +CONFIG_SGETMASK_SYSCALL=y
> +CONFIG_SYSFS_SYSCALL=y
> +CONFIG_KALLSYMS=y
> +# CONFIG_KALLSYMS_ALL is not set
> +CONFIG_PRINTK=y
> +CONFIG_BUG=y
> +CONFIG_PCSPKR_PLATFORM=y
> +CONFIG_BASE_FULL=y
> +CONFIG_FUTEX=y
> +CONFIG_EPOLL=y
> +CONFIG_SIGNALFD=y
> +CONFIG_TIMERFD=y
> +CONFIG_EVENTFD=y
> +CONFIG_SHMEM=y
> +CONFIG_AIO=y
> +# CONFIG_EMBEDDED is not set
> +CONFIG_HAVE_PERF_EVENTS=y
> +
> +#
> +# Kernel Performance Events And Counters
> +#
> +CONFIG_PERF_EVENTS=y
> +# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
> +# CONFIG_VM_EVENT_COUNTERS is not set
> +CONFIG_SLUB_DEBUG=y
> +CONFIG_COMPAT_BRK=y
> +# CONFIG_SLAB is not set
> +CONFIG_SLUB=y
> +# CONFIG_SLOB is not set
> +CONFIG_SLUB_CPU_PARTIAL=y
> +# CONFIG_PROFILING is not set
> +CONFIG_HAVE_OPROFILE=y
> +CONFIG_OPROFILE_NMI_TIMER=y
> +CONFIG_JUMP_LABEL=y
> +# CONFIG_UPROBES is not set
> +# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
> +CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
> +CONFIG_ARCH_USE_BUILTIN_BSWAP=y
> +CONFIG_HAVE_IOREMAP_PROT=y
> +CONFIG_HAVE_KPROBES=y
> +CONFIG_HAVE_KRETPROBES=y
> +CONFIG_HAVE_OPTPROBES=y
> +CONFIG_HAVE_KPROBES_ON_FTRACE=y
> +CONFIG_HAVE_ARCH_TRACEHOOK=y
> +CONFIG_HAVE_DMA_ATTRS=y
> +CONFIG_HAVE_DMA_CONTIGUOUS=y
> +CONFIG_GENERIC_SMP_IDLE_THREAD=y
> +CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
> +CONFIG_HAVE_DMA_API_DEBUG=y
> +CONFIG_HAVE_HW_BREAKPOINT=y
> +CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
> +CONFIG_HAVE_USER_RETURN_NOTIFIER=y
> +CONFIG_HAVE_PERF_EVENTS_NMI=y
> +CONFIG_HAVE_PERF_REGS=y
> +CONFIG_HAVE_PERF_USER_STACK_DUMP=y
> +CONFIG_HAVE_ARCH_JUMP_LABEL=y
> +CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
> +CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
> +CONFIG_HAVE_CMPXCHG_LOCAL=y
> +CONFIG_HAVE_CMPXCHG_DOUBLE=y
> +CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
> +CONFIG_HAVE_CC_STACKPROTECTOR=y
> +CONFIG_CC_STACKPROTECTOR=y
> +# CONFIG_CC_STACKPROTECTOR_NONE is not set
> +CONFIG_CC_STACKPROTECTOR_REGULAR=y
> +# CONFIG_CC_STACKPROTECTOR_STRONG is not set
> +CONFIG_HAVE_CONTEXT_TRACKING=y
> +CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y
> +CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
> +CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
> +CONFIG_HAVE_ARCH_SOFT_DIRTY=y
> +CONFIG_MODULES_USE_ELF_RELA=y
> +CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK=y
> +
> +#
> +# GCOV-based kernel profiling
> +#
> +# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
> +CONFIG_SLABINFO=y
> +CONFIG_RT_MUTEXES=y
> +CONFIG_BASE_SMALL=0
> +# CONFIG_MODULES is not set
> +CONFIG_STOP_MACHINE=y
> +CONFIG_BLOCK=y
> +# CONFIG_BLK_DEV_BSG is not set
> +# CONFIG_BLK_DEV_BSGLIB is not set
> +# CONFIG_BLK_DEV_INTEGRITY is not set
> +CONFIG_BLK_CMDLINE_PARSER=y
> +
> +#
> +# Partition Types
> +#
> +# CONFIG_PARTITION_ADVANCED is not set
> +CONFIG_MSDOS_PARTITION=y
> +CONFIG_EFI_PARTITION=y
> +
> +#
> +# IO Schedulers
> +#
> +CONFIG_IOSCHED_NOOP=y
> +# CONFIG_IOSCHED_DEADLINE is not set
> +# CONFIG_IOSCHED_CFQ is not set
> +CONFIG_DEFAULT_NOOP=y
> +CONFIG_DEFAULT_IOSCHED="noop"
> +CONFIG_UNINLINE_SPIN_UNLOCK=y
> +CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
> +CONFIG_INLINE_READ_UNLOCK=y
> +CONFIG_INLINE_READ_UNLOCK_IRQ=y
> +CONFIG_INLINE_WRITE_UNLOCK=y
> +CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
> +CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
> +CONFIG_MUTEX_SPIN_ON_OWNER=y
> +CONFIG_RWSEM_SPIN_ON_OWNER=y
> +CONFIG_ARCH_USE_QUEUE_RWLOCK=y
> +CONFIG_QUEUE_RWLOCK=y
> +CONFIG_FREEZER=y
> +
> +#
> +# Processor type and features
> +#
> +CONFIG_ZONE_DMA=y
> +CONFIG_SMP=y
> +CONFIG_X86_MPPARSE=y
> +# CONFIG_X86_EXTENDED_PLATFORM is not set
> +# CONFIG_SCHED_OMIT_FRAME_POINTER is not set
> +CONFIG_HYPERVISOR_GUEST=y
> +CONFIG_PARAVIRT=y
> +CONFIG_PARAVIRT_DEBUG=y
> +CONFIG_PARAVIRT_SPINLOCKS=y
> +CONFIG_XEN=y
> +CONFIG_XEN_MAX_DOMAIN_MEMORY=500
> +CONFIG_XEN_SAVE_RESTORE=y
> +# CONFIG_KVM_GUEST is not set
> +# CONFIG_PARAVIRT_TIME_ACCOUNTING is not set
> +CONFIG_PARAVIRT_CLOCK=y
> +CONFIG_NO_BOOTMEM=y
> +# CONFIG_MEMTEST is not set
> +# CONFIG_MK8 is not set
> +# CONFIG_MPSC is not set
> +# CONFIG_MCORE2 is not set
> +# CONFIG_MATOM is not set
> +CONFIG_GENERIC_CPU=y
> +CONFIG_X86_INTERNODE_CACHE_SHIFT=6
> +CONFIG_X86_L1_CACHE_SHIFT=6
> +CONFIG_X86_TSC=y
> +CONFIG_X86_CMPXCHG64=y
> +CONFIG_X86_CMOV=y
> +CONFIG_X86_MINIMUM_CPU_FAMILY=64
> +CONFIG_X86_DEBUGCTLMSR=y
> +# CONFIG_PROCESSOR_SELECT is not set
> +CONFIG_CPU_SUP_INTEL=y
> +CONFIG_CPU_SUP_AMD=y
> +CONFIG_CPU_SUP_CENTAUR=y
> +CONFIG_HPET_TIMER=y
> +CONFIG_DMI=y
> +CONFIG_SWIOTLB=y
> +CONFIG_IOMMU_HELPER=y
> +# CONFIG_MAXSMP is not set
> +CONFIG_NR_CPUS=8
> +# CONFIG_SCHED_SMT is not set
> +CONFIG_SCHED_MC=y
> +CONFIG_PREEMPT_NONE=y
> +# CONFIG_PREEMPT_VOLUNTARY is not set
> +# CONFIG_PREEMPT is not set
> +CONFIG_X86_LOCAL_APIC=y
> +CONFIG_X86_IO_APIC=y
> +# CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set
> +# CONFIG_X86_MCE is not set
> +CONFIG_X86_16BIT=y
> +CONFIG_X86_ESPFIX64=y
> +# CONFIG_I8K is not set
> +# CONFIG_MICROCODE is not set
> +# CONFIG_MICROCODE_INTEL_EARLY is not set
> +# CONFIG_MICROCODE_AMD_EARLY is not set
> +# CONFIG_X86_MSR is not set
> +# CONFIG_X86_CPUID is not set
> +CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
> +CONFIG_ARCH_DMA_ADDR_T_64BIT=y
> +# CONFIG_DIRECT_GBPAGES is not set
> +# CONFIG_NUMA is not set
> +CONFIG_ARCH_SPARSEMEM_ENABLE=y
> +CONFIG_ARCH_SPARSEMEM_DEFAULT=y
> +CONFIG_ARCH_SELECT_MEMORY_MODEL=y
> +CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
> +CONFIG_SELECT_MEMORY_MODEL=y
> +CONFIG_SPARSEMEM_MANUAL=y
> +CONFIG_SPARSEMEM=y
> +CONFIG_HAVE_MEMORY_PRESENT=y
> +CONFIG_SPARSEMEM_EXTREME=y
> +CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
> +CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y
> +CONFIG_SPARSEMEM_VMEMMAP=y
> +CONFIG_HAVE_MEMBLOCK=y
> +CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
> +CONFIG_ARCH_DISCARD_MEMBLOCK=y
> +# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
> +# CONFIG_MEMORY_HOTPLUG is not set
> +CONFIG_PAGEFLAGS_EXTENDED=y
> +CONFIG_SPLIT_PTLOCK_CPUS=4
> +CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y
> +# CONFIG_COMPACTION is not set
> +CONFIG_PHYS_ADDR_T_64BIT=y
> +CONFIG_ZONE_DMA_FLAG=1
> +CONFIG_BOUNCE=y
> +CONFIG_VIRT_TO_BUS=y
> +CONFIG_MMU_NOTIFIER=y
> +# CONFIG_KSM is not set
> +CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
> +# CONFIG_TRANSPARENT_HUGEPAGE is not set
> +# CONFIG_CLEANCACHE is not set
> +# CONFIG_CMA is not set
> +# CONFIG_ZPOOL is not set
> +# CONFIG_ZBUD is not set
> +# CONFIG_ZSMALLOC is not set
> +CONFIG_GENERIC_EARLY_IOREMAP=y
> +# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
> +CONFIG_X86_RESERVE_LOW=32
> +CONFIG_MTRR=y
> +# CONFIG_MTRR_SANITIZER is not set
> +CONFIG_X86_PAT=y
> +CONFIG_ARCH_USES_PG_UNCACHED=y
> +CONFIG_ARCH_RANDOM=y
> +# CONFIG_X86_SMAP is not set
> +# CONFIG_SECCOMP is not set
> +# CONFIG_HZ_100 is not set
> +CONFIG_HZ_250=y
> +# CONFIG_HZ_300 is not set
> +# CONFIG_HZ_1000 is not set
> +CONFIG_HZ=250
> +# CONFIG_SCHED_HRTICK is not set
> +# CONFIG_KEXEC is not set
> +# CONFIG_CRASH_DUMP is not set
> +CONFIG_PHYSICAL_START=0x1000000
> +CONFIG_RELOCATABLE=y
> +# CONFIG_RANDOMIZE_BASE is not set
> +CONFIG_PHYSICAL_ALIGN=0x1000000
> +CONFIG_HOTPLUG_CPU=y
> +# CONFIG_BOOTPARAM_HOTPLUG_CPU0 is not set
> +# CONFIG_DEBUG_HOTPLUG_CPU0 is not set
> +# CONFIG_CMDLINE_BOOL is not set
> +CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
> +
> +#
> +# Power management and ACPI options
> +#
> +# CONFIG_SUSPEND is not set
> +CONFIG_HIBERNATE_CALLBACKS=y
> +CONFIG_PM_SLEEP=y
> +CONFIG_PM_SLEEP_SMP=y
> +# CONFIG_PM_AUTOSLEEP is not set
> +# CONFIG_PM_WAKELOCKS is not set
> +# CONFIG_PM_RUNTIME is not set
> +CONFIG_PM=y
> +# CONFIG_PM_DEBUG is not set
> +# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
> +# CONFIG_SFI is not set
> +
> +#
> +# CPU Frequency scaling
> +#
> +# CONFIG_CPU_FREQ is not set
> +
> +#
> +# CPU Idle
> +#
> +# CONFIG_CPU_IDLE is not set
> +# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
> +
> +#
> +# Memory power savings
> +#
> +# CONFIG_I7300_IDLE is not set
> +
> +#
> +# Bus options (PCI etc.)
> +#
> +# CONFIG_PCI is not set
> +CONFIG_PCI_LABEL=y
> +CONFIG_ISA_DMA_API=y
> +# CONFIG_PCCARD is not set
> +CONFIG_X86_SYSFB=y
> +
> +#
> +# Executable file formats / Emulations
> +#
> +CONFIG_BINFMT_ELF=y
> +CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
> +CONFIG_BINFMT_SCRIPT=y
> +# CONFIG_HAVE_AOUT is not set
> +# CONFIG_BINFMT_MISC is not set
> +# CONFIG_COREDUMP is not set
> +# CONFIG_IA32_EMULATION is not set
> +CONFIG_X86_DEV_DMA_OPS=y
> +CONFIG_NET=y
> +
> +#
> +# Networking options
> +#
> +CONFIG_PACKET=y
> +# CONFIG_PACKET_DIAG is not set
> +CONFIG_UNIX=y
> +# CONFIG_UNIX_DIAG is not set
> +# CONFIG_XFRM_USER is not set
> +# CONFIG_NET_KEY is not set
> +CONFIG_INET=y
> +# CONFIG_IP_MULTICAST is not set
> +# CONFIG_IP_ADVANCED_ROUTER is not set
> +# CONFIG_IP_PNP is not set
> +# CONFIG_NET_IPIP is not set
> +# CONFIG_NET_IPGRE_DEMUX is not set
> +# CONFIG_NET_IP_TUNNEL is not set
> +# CONFIG_SYN_COOKIES is not set
> +# CONFIG_NET_UDP_TUNNEL is not set
> +# CONFIG_INET_AH is not set
> +# CONFIG_INET_ESP is not set
> +# CONFIG_INET_IPCOMP is not set
> +# CONFIG_INET_XFRM_TUNNEL is not set
> +# CONFIG_INET_TUNNEL is not set
> +# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
> +# CONFIG_INET_XFRM_MODE_TUNNEL is not set
> +# CONFIG_INET_XFRM_MODE_BEET is not set
> +# CONFIG_INET_LRO is not set
> +# CONFIG_INET_DIAG is not set
> +# CONFIG_TCP_CONG_ADVANCED is not set
> +CONFIG_TCP_CONG_CUBIC=y
> +CONFIG_DEFAULT_TCP_CONG="cubic"
> +# CONFIG_TCP_MD5SIG is not set
> +# CONFIG_IPV6 is not set
> +# CONFIG_NETWORK_SECMARK is not set
> +# CONFIG_NET_PTP_CLASSIFY is not set
> +# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
> +# CONFIG_NETFILTER is not set
> +# CONFIG_IP_DCCP is not set
> +# CONFIG_IP_SCTP is not set
> +# CONFIG_RDS is not set
> +# CONFIG_TIPC is not set
> +# CONFIG_ATM is not set
> +# CONFIG_L2TP is not set
> +CONFIG_STP=y
> +CONFIG_BRIDGE=y
> +# CONFIG_BRIDGE_IGMP_SNOOPING is not set
> +CONFIG_HAVE_NET_DSA=y
> +# CONFIG_VLAN_8021Q is not set
> +# CONFIG_DECNET is not set
> +CONFIG_LLC=y
> +# CONFIG_LLC2 is not set
> +# CONFIG_IPX is not set
> +# CONFIG_ATALK is not set
> +# CONFIG_X25 is not set
> +# CONFIG_LAPB is not set
> +# CONFIG_PHONET is not set
> +# CONFIG_IEEE802154 is not set
> +# CONFIG_NET_SCHED is not set
> +# CONFIG_DCB is not set
> +# CONFIG_BATMAN_ADV is not set
> +# CONFIG_OPENVSWITCH is not set
> +# CONFIG_VSOCKETS is not set
> +# CONFIG_NETLINK_MMAP is not set
> +# CONFIG_NETLINK_DIAG is not set
> +# CONFIG_NET_MPLS_GSO is not set
> +# CONFIG_HSR is not set
> +CONFIG_RPS=y
> +CONFIG_RFS_ACCEL=y
> +CONFIG_XPS=y
> +CONFIG_NET_RX_BUSY_POLL=y
> +CONFIG_BQL=y
> +CONFIG_NET_FLOW_LIMIT=y
> +
> +#
> +# Network testing
> +#
> +# CONFIG_NET_PKTGEN is not set
> +# CONFIG_HAMRADIO is not set
> +# CONFIG_CAN is not set
> +# CONFIG_IRDA is not set
> +# CONFIG_BT is not set
> +# CONFIG_AF_RXRPC is not set
> +# CONFIG_WIRELESS is not set
> +# CONFIG_WIMAX is not set
> +# CONFIG_RFKILL is not set
> +# CONFIG_NET_9P is not set
> +# CONFIG_CAIF is not set
> +# CONFIG_CEPH_LIB is not set
> +# CONFIG_NFC is not set
> +CONFIG_HAVE_BPF_JIT=y
> +
> +#
> +# Device Drivers
> +#
> +
> +#
> +# Generic Driver Options
> +#
> +CONFIG_UEVENT_HELPER=y
> +CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
> +CONFIG_DEVTMPFS=y
> +CONFIG_DEVTMPFS_MOUNT=y
> +CONFIG_STANDALONE=y
> +# CONFIG_PREVENT_FIRMWARE_BUILD is not set
> +CONFIG_FW_LOADER=y
> +# CONFIG_FIRMWARE_IN_KERNEL is not set
> +CONFIG_EXTRA_FIRMWARE=""
> +# CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set
> +# CONFIG_DEBUG_DRIVER is not set
> +# CONFIG_DEBUG_DEVRES is not set
> +CONFIG_SYS_HYPERVISOR=y
> +# CONFIG_GENERIC_CPU_DEVICES is not set
> +CONFIG_GENERIC_CPU_AUTOPROBE=y
> +# CONFIG_DMA_SHARED_BUFFER is not set
> +
> +#
> +# Bus devices
> +#
> +# CONFIG_CONNECTOR is not set
> +# CONFIG_MTD is not set
> +CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
> +# CONFIG_PARPORT is not set
> +CONFIG_BLK_DEV=y
> +# CONFIG_BLK_DEV_NULL_BLK is not set
> +# CONFIG_BLK_DEV_FD is not set
> +# CONFIG_BLK_DEV_COW_COMMON is not set
> +# CONFIG_BLK_DEV_LOOP is not set
> +# CONFIG_BLK_DEV_DRBD is not set
> +# CONFIG_BLK_DEV_NBD is not set
> +# CONFIG_BLK_DEV_RAM is not set
> +# CONFIG_CDROM_PKTCDVD is not set
> +# CONFIG_ATA_OVER_ETH is not set
> +CONFIG_XEN_BLKDEV_FRONTEND=y
> +# CONFIG_BLK_DEV_HD is not set
> +# CONFIG_BLK_DEV_RBD is not set
> +
> +#
> +# Misc devices
> +#
> +# CONFIG_SENSORS_LIS3LV02D is not set
> +# CONFIG_DUMMY_IRQ is not set
> +# CONFIG_ENCLOSURE_SERVICES is not set
> +# CONFIG_VMWARE_BALLOON is not set
> +# CONFIG_SRAM is not set
> +# CONFIG_C2PORT is not set
> +
> +#
> +# EEPROM support
> +#
> +# CONFIG_EEPROM_93CX6 is not set
> +
> +#
> +# Texas Instruments shared transport line discipline
> +#
> +
> +#
> +# Altera FPGA firmware download module
> +#
> +
> +#
> +# Intel MIC Bus Driver
> +#
> +
> +#
> +# Intel MIC Host Driver
> +#
> +
> +#
> +# Intel MIC Card Driver
> +#
> +# CONFIG_ECHO is not set
> +CONFIG_HAVE_IDE=y
> +# CONFIG_IDE is not set
> +
> +#
> +# SCSI device support
> +#
> +CONFIG_SCSI_MOD=y
> +# CONFIG_RAID_ATTRS is not set
> +# CONFIG_SCSI is not set
> +# CONFIG_SCSI_DMA is not set
> +# CONFIG_SCSI_NETLINK is not set
> +# CONFIG_ATA is not set
> +# CONFIG_MD is not set
> +# CONFIG_MACINTOSH_DRIVERS is not set
> +CONFIG_NETDEVICES=y
> +CONFIG_NET_CORE=y
> +# CONFIG_BONDING is not set
> +# CONFIG_DUMMY is not set
> +# CONFIG_EQUALIZER is not set
> +# CONFIG_NET_TEAM is not set
> +# CONFIG_MACVLAN is not set
> +# CONFIG_VXLAN is not set
> +# CONFIG_NETCONSOLE is not set
> +# CONFIG_NETPOLL is not set
> +# CONFIG_NET_POLL_CONTROLLER is not set
> +CONFIG_TUN=y
> +# CONFIG_VETH is not set
> +# CONFIG_NLMON is not set
> +
> +#
> +# CAIF transport drivers
> +#
> +# CONFIG_VHOST_NET is not set
> +
> +#
> +# Distributed Switch Architecture drivers
> +#
> +# CONFIG_NET_DSA_MV88E6XXX is not set
> +# CONFIG_NET_DSA_MV88E6060 is not set
> +# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
> +# CONFIG_NET_DSA_MV88E6131 is not set
> +# CONFIG_NET_DSA_MV88E6123_61_65 is not set
> +# CONFIG_ETHERNET is not set
> +# CONFIG_PHYLIB is not set
> +# CONFIG_PPP is not set
> +# CONFIG_SLIP is not set
> +
> +#
> +# Host-side USB support is needed for USB Network Adapter support
> +#
> +# CONFIG_WLAN is not set
> +
> +#
> +# Enable WiMAX (Networking options) to see the WiMAX drivers
> +#
> +# CONFIG_WAN is not set
> +CONFIG_XEN_NETDEV_FRONTEND=y
> +# CONFIG_ISDN is not set
> +
> +#
> +# Input device support
> +#
> +CONFIG_INPUT=y
> +# CONFIG_INPUT_FF_MEMLESS is not set
> +# CONFIG_INPUT_POLLDEV is not set
> +# CONFIG_INPUT_SPARSEKMAP is not set
> +# CONFIG_INPUT_MATRIXKMAP is not set
> +
> +#
> +# Userland interfaces
> +#
> +CONFIG_INPUT_MOUSEDEV=y
> +# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
> +CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
> +CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
> +# CONFIG_INPUT_JOYDEV is not set
> +# CONFIG_INPUT_EVDEV is not set
> +# CONFIG_INPUT_EVBUG is not set
> +
> +#
> +# Input Device Drivers
> +#
> +CONFIG_INPUT_KEYBOARD=y
> +CONFIG_KEYBOARD_ATKBD=y
> +# CONFIG_KEYBOARD_LKKBD is not set
> +# CONFIG_KEYBOARD_NEWTON is not set
> +# CONFIG_KEYBOARD_OPENCORES is not set
> +# CONFIG_KEYBOARD_STOWAWAY is not set
> +# CONFIG_KEYBOARD_SUNKBD is not set
> +# CONFIG_KEYBOARD_XTKBD is not set
> +# CONFIG_INPUT_MOUSE is not set
> +# CONFIG_INPUT_JOYSTICK is not set
> +# CONFIG_INPUT_TABLET is not set
> +# CONFIG_INPUT_TOUCHSCREEN is not set
> +CONFIG_INPUT_MISC=y
> +# CONFIG_INPUT_AD714X is not set
> +# CONFIG_INPUT_PCSPKR is not set
> +# CONFIG_INPUT_UINPUT is not set
> +# CONFIG_INPUT_ADXL34X is not set
> +# CONFIG_INPUT_CMA3000 is not set
> +CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
> +# CONFIG_INPUT_IDEAPAD_SLIDEBAR is not set
> +
> +#
> +# Hardware I/O ports
> +#
> +CONFIG_SERIO=y
> +CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y
> +CONFIG_SERIO_I8042=y
> +# CONFIG_SERIO_SERPORT is not set
> +# CONFIG_SERIO_CT82C710 is not set
> +CONFIG_SERIO_LIBPS2=y
> +# CONFIG_SERIO_RAW is not set
> +# CONFIG_SERIO_ALTERA_PS2 is not set
> +# CONFIG_SERIO_PS2MULT is not set
> +# CONFIG_SERIO_ARC_PS2 is not set
> +# CONFIG_GAMEPORT is not set
> +
> +#
> +# Character devices
> +#
> +CONFIG_TTY=y
> +CONFIG_VT=y
> +CONFIG_CONSOLE_TRANSLATIONS=y
> +CONFIG_VT_CONSOLE=y
> +CONFIG_VT_CONSOLE_SLEEP=y
> +CONFIG_HW_CONSOLE=y
> +CONFIG_VT_HW_CONSOLE_BINDING=y
> +CONFIG_UNIX98_PTYS=y
> +# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
> +# CONFIG_LEGACY_PTYS is not set
> +# CONFIG_SERIAL_NONSTANDARD is not set
> +# CONFIG_N_GSM is not set
> +# CONFIG_TRACE_SINK is not set
> +# CONFIG_DEVKMEM is not set
> +
> +#
> +# Serial drivers
> +#
> +# CONFIG_SERIAL_8250 is not set
> +
> +#
> +# Non-8250 serial port support
> +#
> +# CONFIG_SERIAL_SCCNXP is not set
> +# CONFIG_SERIAL_ALTERA_JTAGUART is not set
> +# CONFIG_SERIAL_ALTERA_UART is not set
> +# CONFIG_SERIAL_ARC is not set
> +# CONFIG_SERIAL_FSL_LPUART is not set
> +# CONFIG_TTY_PRINTK is not set
> +CONFIG_HVC_DRIVER=y
> +CONFIG_HVC_IRQ=y
> +CONFIG_HVC_XEN=y
> +CONFIG_HVC_XEN_FRONTEND=y
> +# CONFIG_IPMI_HANDLER is not set
> +# CONFIG_HW_RANDOM is not set
> +# CONFIG_NVRAM is not set
> +# CONFIG_R3964 is not set
> +# CONFIG_MWAVE is not set
> +# CONFIG_RAW_DRIVER is not set
> +# CONFIG_HANGCHECK_TIMER is not set
> +# CONFIG_TCG_TPM is not set
> +# CONFIG_TELCLOCK is not set
> +
> +#
> +# I2C support
> +#
> +# CONFIG_I2C is not set
> +# CONFIG_SPI is not set
> +# CONFIG_SPMI is not set
> +# CONFIG_HSI is not set
> +
> +#
> +# PPS support
> +#
> +# CONFIG_PPS is not set
> +
> +#
> +# PPS generators support
> +#
> +
> +#
> +# PTP clock support
> +#
> +# CONFIG_PTP_1588_CLOCK is not set
> +
> +#
> +# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
> +#
> +CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
> +# CONFIG_GPIOLIB is not set
> +# CONFIG_W1 is not set
> +# CONFIG_POWER_SUPPLY is not set
> +# CONFIG_POWER_AVS is not set
> +# CONFIG_HWMON is not set
> +# CONFIG_THERMAL is not set
> +# CONFIG_WATCHDOG is not set
> +CONFIG_SSB_POSSIBLE=y
> +
> +#
> +# Sonics Silicon Backplane
> +#
> +# CONFIG_SSB is not set
> +CONFIG_BCMA_POSSIBLE=y
> +
> +#
> +# Broadcom specific AMBA
> +#
> +# CONFIG_BCMA is not set
> +
> +#
> +# Multifunction device drivers
> +#
> +# CONFIG_MFD_CORE is not set
> +# CONFIG_MFD_CROS_EC is not set
> +# CONFIG_HTC_PASIC3 is not set
> +# CONFIG_MFD_KEMPLD is not set
> +# CONFIG_MFD_SM501 is not set
> +# CONFIG_ABX500_CORE is not set
> +# CONFIG_MFD_SYSCON is not set
> +# CONFIG_MFD_TI_AM335X_TSCADC is not set
> +# CONFIG_MFD_TMIO is not set
> +# CONFIG_REGULATOR is not set
> +# CONFIG_MEDIA_SUPPORT is not set
> +
> +#
> +# Graphics support
> +#
> +
> +#
> +# Direct Rendering Manager
> +#
> +# CONFIG_DRM is not set
> +
> +#
> +# Frame buffer Devices
> +#
> +CONFIG_FB=y
> +# CONFIG_FIRMWARE_EDID is not set
> +# CONFIG_FB_DDC is not set
> +# CONFIG_FB_BOOT_VESA_SUPPORT is not set
> +# CONFIG_FB_CFB_FILLRECT is not set
> +# CONFIG_FB_CFB_COPYAREA is not set
> +# CONFIG_FB_CFB_IMAGEBLIT is not set
> +# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
> +CONFIG_FB_SYS_FILLRECT=y
> +CONFIG_FB_SYS_COPYAREA=y
> +CONFIG_FB_SYS_IMAGEBLIT=y
> +# CONFIG_FB_FOREIGN_ENDIAN is not set
> +CONFIG_FB_SYS_FOPS=y
> +CONFIG_FB_DEFERRED_IO=y
> +# CONFIG_FB_SVGALIB is not set
> +# CONFIG_FB_MACMODES is not set
> +# CONFIG_FB_BACKLIGHT is not set
> +# CONFIG_FB_MODE_HELPERS is not set
> +# CONFIG_FB_TILEBLITTING is not set
> +
> +#
> +# Frame buffer hardware drivers
> +#
> +# CONFIG_FB_ARC is not set
> +# CONFIG_FB_VGA16 is not set
> +# CONFIG_FB_VESA is not set
> +# CONFIG_FB_N411 is not set
> +# CONFIG_FB_HGA is not set
> +# CONFIG_FB_OPENCORES is not set
> +# CONFIG_FB_S1D13XXX is not set
> +# CONFIG_FB_VIRTUAL is not set
> +CONFIG_XEN_FBDEV_FRONTEND=y
> +# CONFIG_FB_METRONOME is not set
> +# CONFIG_FB_BROADSHEET is not set
> +# CONFIG_FB_AUO_K190X is not set
> +# CONFIG_FB_SIMPLE is not set
> +# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
> +# CONFIG_VGASTATE is not set
> +
> +#
> +# Console display driver support
> +#
> +# CONFIG_VGA_CONSOLE is not set
> +CONFIG_DUMMY_CONSOLE=y
> +# CONFIG_FRAMEBUFFER_CONSOLE is not set
> +# CONFIG_LOGO is not set
> +# CONFIG_SOUND is not set
> +
> +#
> +# HID support
> +#
> +# CONFIG_HID is not set
> +CONFIG_USB_OHCI_LITTLE_ENDIAN=y
> +# CONFIG_USB_SUPPORT is not set
> +# CONFIG_MMC is not set
> +# CONFIG_MEMSTICK is not set
> +# CONFIG_NEW_LEDS is not set
> +# CONFIG_ACCESSIBILITY is not set
> +# CONFIG_EDAC is not set
> +CONFIG_RTC_LIB=y
> +# CONFIG_RTC_CLASS is not set
> +# CONFIG_DMADEVICES is not set
> +# CONFIG_AUXDISPLAY is not set
> +# CONFIG_UIO is not set
> +# CONFIG_VIRT_DRIVERS is not set
> +
> +#
> +# Virtio drivers
> +#
> +# CONFIG_VIRTIO_MMIO is not set
> +
> +#
> +# Microsoft Hyper-V guest support
> +#
> +
> +#
> +# Xen driver support
> +#
> +# CONFIG_XEN_BALLOON is not set
> +CONFIG_XEN_DEV_EVTCHN=y
> +CONFIG_XENFS=y
> +CONFIG_XEN_COMPAT_XENFS=y
> +CONFIG_XEN_SYS_HYPERVISOR=y
> +CONFIG_XEN_XENBUS_FRONTEND=y
> +CONFIG_XEN_GNTDEV=y
> +CONFIG_XEN_GRANT_DEV_ALLOC=y
> +CONFIG_SWIOTLB_XEN=y
> +CONFIG_XEN_PRIVCMD=y
> +CONFIG_XEN_HAVE_PVMMU=y
> +# CONFIG_STAGING is not set
> +# CONFIG_X86_PLATFORM_DEVICES is not set
> +# CONFIG_CHROME_PLATFORMS is not set
> +
> +#
> +# SOC (System On Chip) specific Drivers
> +#
> +
> +#
> +# Hardware Spinlock drivers
> +#
> +
> +#
> +# Clock Source drivers
> +#
> +CONFIG_CLKEVT_I8253=y
> +CONFIG_I8253_LOCK=y
> +CONFIG_CLKBLD_I8253=y
> +# CONFIG_SH_TIMER_CMT is not set
> +# CONFIG_SH_TIMER_MTU2 is not set
> +# CONFIG_SH_TIMER_TMU is not set
> +# CONFIG_EM_TIMER_STI is not set
> +# CONFIG_MAILBOX is not set
> +# CONFIG_IOMMU_SUPPORT is not set
> +
> +#
> +# Remoteproc drivers
> +#
> +# CONFIG_STE_MODEM_RPROC is not set
> +
> +#
> +# Rpmsg drivers
> +#
> +# CONFIG_PM_DEVFREQ is not set
> +# CONFIG_EXTCON is not set
> +# CONFIG_MEMORY is not set
> +# CONFIG_IIO is not set
> +# CONFIG_PWM is not set
> +# CONFIG_IPACK_BUS is not set
> +# CONFIG_RESET_CONTROLLER is not set
> +# CONFIG_FMC is not set
> +
> +#
> +# PHY Subsystem
> +#
> +# CONFIG_GENERIC_PHY is not set
> +# CONFIG_BCM_KONA_USB2_PHY is not set
> +# CONFIG_POWERCAP is not set
> +# CONFIG_MCB is not set
> +
> +#
> +# Firmware Drivers
> +#
> +# CONFIG_EDD is not set
> +CONFIG_FIRMWARE_MEMMAP=y
> +# CONFIG_DELL_RBU is not set
> +# CONFIG_DCDBAS is not set
> +# CONFIG_DMIID is not set
> +# CONFIG_DMI_SYSFS is not set
> +CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y
> +# CONFIG_GOOGLE_FIRMWARE is not set
> +
> +#
> +# File systems
> +#
> +CONFIG_DCACHE_WORD_ACCESS=y
> +CONFIG_EXT2_FS=y
> +# CONFIG_EXT2_FS_XATTR is not set
> +# CONFIG_EXT2_FS_XIP is not set
> +# CONFIG_EXT3_FS is not set
> +# CONFIG_EXT4_FS is not set
> +# CONFIG_REISERFS_FS is not set
> +# CONFIG_JFS_FS is not set
> +# CONFIG_XFS_FS is not set
> +# CONFIG_GFS2_FS is not set
> +# CONFIG_BTRFS_FS is not set
> +# CONFIG_NILFS2_FS is not set
> +# CONFIG_FS_POSIX_ACL is not set
> +CONFIG_FILE_LOCKING=y
> +CONFIG_FSNOTIFY=y
> +# CONFIG_DNOTIFY is not set
> +CONFIG_INOTIFY_USER=y
> +# CONFIG_FANOTIFY is not set
> +# CONFIG_QUOTA is not set
> +# CONFIG_QUOTACTL is not set
> +CONFIG_AUTOFS4_FS=y
> +# CONFIG_FUSE_FS is not set
> +
> +#
> +# Caches
> +#
> +# CONFIG_FSCACHE is not set
> +
> +#
> +# CD-ROM/DVD Filesystems
> +#
> +# CONFIG_ISO9660_FS is not set
> +# CONFIG_UDF_FS is not set
> +
> +#
> +# DOS/FAT/NT Filesystems
> +#
> +# CONFIG_MSDOS_FS is not set
> +# CONFIG_VFAT_FS is not set
> +# CONFIG_NTFS_FS is not set
> +
> +#
> +# Pseudo filesystems
> +#
> +CONFIG_PROC_FS=y
> +# CONFIG_PROC_KCORE is not set
> +# CONFIG_PROC_SYSCTL is not set
> +# CONFIG_PROC_PAGE_MONITOR is not set
> +CONFIG_KERNFS=y
> +CONFIG_SYSFS=y
> +# CONFIG_TMPFS is not set
> +# CONFIG_HUGETLBFS is not set
> +# CONFIG_HUGETLB_PAGE is not set
> +# CONFIG_CONFIGFS_FS is not set
> +CONFIG_MISC_FILESYSTEMS=y
> +# CONFIG_ADFS_FS is not set
> +# CONFIG_AFFS_FS is not set
> +# CONFIG_HFS_FS is not set
> +# CONFIG_HFSPLUS_FS is not set
> +# CONFIG_BEFS_FS is not set
> +# CONFIG_BFS_FS is not set
> +# CONFIG_EFS_FS is not set
> +# CONFIG_LOGFS is not set
> +CONFIG_CRAMFS=y
> +CONFIG_SQUASHFS=y
> +CONFIG_SQUASHFS_FILE_CACHE=y
> +# CONFIG_SQUASHFS_FILE_DIRECT is not set
> +CONFIG_SQUASHFS_DECOMP_SINGLE=y
> +# CONFIG_SQUASHFS_DECOMP_MULTI is not set
> +# CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU is not set
> +# CONFIG_SQUASHFS_XATTR is not set
> +CONFIG_SQUASHFS_ZLIB=y
> +# CONFIG_SQUASHFS_LZO is not set
> +# CONFIG_SQUASHFS_XZ is not set
> +# CONFIG_SQUASHFS_4K_DEVBLK_SIZE is not set
> +# CONFIG_SQUASHFS_EMBEDDED is not set
> +CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3
> +# CONFIG_VXFS_FS is not set
> +# CONFIG_MINIX_FS is not set
> +# CONFIG_OMFS_FS is not set
> +# CONFIG_HPFS_FS is not set
> +# CONFIG_QNX4FS_FS is not set
> +# CONFIG_QNX6FS_FS is not set
> +CONFIG_ROMFS_FS=y
> +CONFIG_ROMFS_BACKED_BY_BLOCK=y
> +CONFIG_ROMFS_ON_BLOCK=y
> +# CONFIG_PSTORE is not set
> +# CONFIG_SYSV_FS is not set
> +# CONFIG_UFS_FS is not set
> +# CONFIG_F2FS_FS is not set
> +# CONFIG_NETWORK_FILESYSTEMS is not set
> +CONFIG_NLS=y
> +CONFIG_NLS_DEFAULT="iso8859-1"
> +# CONFIG_NLS_CODEPAGE_437 is not set
> +# CONFIG_NLS_CODEPAGE_737 is not set
> +# CONFIG_NLS_CODEPAGE_775 is not set
> +# CONFIG_NLS_CODEPAGE_850 is not set
> +# CONFIG_NLS_CODEPAGE_852 is not set
> +# CONFIG_NLS_CODEPAGE_855 is not set
> +# CONFIG_NLS_CODEPAGE_857 is not set
> +# CONFIG_NLS_CODEPAGE_860 is not set
> +# CONFIG_NLS_CODEPAGE_861 is not set
> +# CONFIG_NLS_CODEPAGE_862 is not set
> +# CONFIG_NLS_CODEPAGE_863 is not set
> +# CONFIG_NLS_CODEPAGE_864 is not set
> +# CONFIG_NLS_CODEPAGE_865 is not set
> +# CONFIG_NLS_CODEPAGE_866 is not set
> +# CONFIG_NLS_CODEPAGE_869 is not set
> +# CONFIG_NLS_CODEPAGE_936 is not set
> +# CONFIG_NLS_CODEPAGE_950 is not set
> +# CONFIG_NLS_CODEPAGE_932 is not set
> +# CONFIG_NLS_CODEPAGE_949 is not set
> +# CONFIG_NLS_CODEPAGE_874 is not set
> +# CONFIG_NLS_ISO8859_8 is not set
> +# CONFIG_NLS_CODEPAGE_1250 is not set
> +# CONFIG_NLS_CODEPAGE_1251 is not set
> +# CONFIG_NLS_ASCII is not set
> +# CONFIG_NLS_ISO8859_1 is not set
> +# CONFIG_NLS_ISO8859_2 is not set
> +# CONFIG_NLS_ISO8859_3 is not set
> +# CONFIG_NLS_ISO8859_4 is not set
> +# CONFIG_NLS_ISO8859_5 is not set
> +# CONFIG_NLS_ISO8859_6 is not set
> +# CONFIG_NLS_ISO8859_7 is not set
> +# CONFIG_NLS_ISO8859_9 is not set
> +# CONFIG_NLS_ISO8859_13 is not set
> +# CONFIG_NLS_ISO8859_14 is not set
> +# CONFIG_NLS_ISO8859_15 is not set
> +# CONFIG_NLS_KOI8_R is not set
> +# CONFIG_NLS_KOI8_U is not set
> +# CONFIG_NLS_MAC_ROMAN is not set
> +# CONFIG_NLS_MAC_CELTIC is not set
> +# CONFIG_NLS_MAC_CENTEURO is not set
> +# CONFIG_NLS_MAC_CROATIAN is not set
> +# CONFIG_NLS_MAC_CYRILLIC is not set
> +# CONFIG_NLS_MAC_GAELIC is not set
> +# CONFIG_NLS_MAC_GREEK is not set
> +# CONFIG_NLS_MAC_ICELAND is not set
> +# CONFIG_NLS_MAC_INUIT is not set
> +# CONFIG_NLS_MAC_ROMANIAN is not set
> +# CONFIG_NLS_MAC_TURKISH is not set
> +# CONFIG_NLS_UTF8 is not set
> +
> +#
> +# Kernel hacking
> +#
> +CONFIG_TRACE_IRQFLAGS_SUPPORT=y
> +
> +#
> +# printk and dmesg options
> +#
> +# CONFIG_PRINTK_TIME is not set
> +CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4
> +# CONFIG_BOOT_PRINTK_DELAY is not set
> +
> +#
> +# Compile-time checks and compiler options
> +#
> +# CONFIG_DEBUG_INFO is not set
> +# CONFIG_ENABLE_WARN_DEPRECATED is not set
> +# CONFIG_ENABLE_MUST_CHECK is not set
> +CONFIG_FRAME_WARN=1024
> +# CONFIG_STRIP_ASM_SYMS is not set
> +# CONFIG_READABLE_ASM is not set
> +# CONFIG_UNUSED_SYMBOLS is not set
> +# CONFIG_DEBUG_FS is not set
> +# CONFIG_HEADERS_CHECK is not set
> +# CONFIG_DEBUG_SECTION_MISMATCH is not set
> +CONFIG_ARCH_WANT_FRAME_POINTERS=y
> +# CONFIG_FRAME_POINTER is not set
> +# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
> +# CONFIG_MAGIC_SYSRQ is not set
> +CONFIG_DEBUG_KERNEL=y
> +
> +#
> +# Memory Debugging
> +#
> +# CONFIG_DEBUG_PAGEALLOC is not set
> +# CONFIG_DEBUG_OBJECTS is not set
> +# CONFIG_SLUB_DEBUG_ON is not set
> +# CONFIG_SLUB_STATS is not set
> +CONFIG_HAVE_DEBUG_KMEMLEAK=y
> +# CONFIG_DEBUG_KMEMLEAK is not set
> +# CONFIG_DEBUG_STACK_USAGE is not set
> +# CONFIG_DEBUG_VM is not set
> +# CONFIG_DEBUG_VIRTUAL is not set
> +CONFIG_DEBUG_MEMORY_INIT=y
> +# CONFIG_DEBUG_PER_CPU_MAPS is not set
> +CONFIG_HAVE_DEBUG_STACKOVERFLOW=y
> +# CONFIG_DEBUG_STACKOVERFLOW is not set
> +CONFIG_HAVE_ARCH_KMEMCHECK=y
> +# CONFIG_KMEMCHECK is not set
> +# CONFIG_DEBUG_SHIRQ is not set
> +
> +#
> +# Debug Lockups and Hangs
> +#
> +# CONFIG_LOCKUP_DETECTOR is not set
> +# CONFIG_DETECT_HUNG_TASK is not set
> +# CONFIG_PANIC_ON_OOPS is not set
> +CONFIG_PANIC_ON_OOPS_VALUE=0
> +CONFIG_PANIC_TIMEOUT=0
> +# CONFIG_SCHED_DEBUG is not set
> +# CONFIG_SCHEDSTATS is not set
> +# CONFIG_TIMER_STATS is not set
> +
> +#
> +# Lock Debugging (spinlocks, mutexes, etc...)
> +#
> +# CONFIG_DEBUG_RT_MUTEXES is not set
> +# CONFIG_DEBUG_SPINLOCK is not set
> +# CONFIG_DEBUG_MUTEXES is not set
> +# CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set
> +# CONFIG_DEBUG_LOCK_ALLOC is not set
> +# CONFIG_PROVE_LOCKING is not set
> +# CONFIG_LOCK_STAT is not set
> +# CONFIG_DEBUG_ATOMIC_SLEEP is not set
> +# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
> +# CONFIG_LOCK_TORTURE_TEST is not set
> +# CONFIG_STACKTRACE is not set
> +# CONFIG_DEBUG_KOBJECT is not set
> +CONFIG_DEBUG_BUGVERBOSE=y
> +# CONFIG_DEBUG_LIST is not set
> +# CONFIG_DEBUG_PI_LIST is not set
> +# CONFIG_DEBUG_SG is not set
> +# CONFIG_DEBUG_NOTIFIERS is not set
> +# CONFIG_DEBUG_CREDENTIALS is not set
> +
> +#
> +# RCU Debugging
> +#
> +# CONFIG_SPARSE_RCU_POINTER is not set
> +# CONFIG_TORTURE_TEST is not set
> +# CONFIG_RCU_TORTURE_TEST is not set
> +CONFIG_RCU_CPU_STALL_TIMEOUT=21
> +# CONFIG_RCU_CPU_STALL_INFO is not set
> +# CONFIG_RCU_TRACE is not set
> +# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
> +# CONFIG_NOTIFIER_ERROR_INJECTION is not set
> +# CONFIG_FAULT_INJECTION is not set
> +# CONFIG_LATENCYTOP is not set
> +CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS=y
> +# CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set
> +CONFIG_USER_STACKTRACE_SUPPORT=y
> +CONFIG_HAVE_FUNCTION_TRACER=y
> +CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
> +CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
> +CONFIG_HAVE_DYNAMIC_FTRACE=y
> +CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y
> +CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
> +CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
> +CONFIG_HAVE_FENTRY=y
> +CONFIG_HAVE_C_RECORDMCOUNT=y
> +CONFIG_TRACING_SUPPORT=y
> +# CONFIG_FTRACE is not set
> +
> +#
> +# Runtime Testing
> +#
> +# CONFIG_TEST_LIST_SORT is not set
> +# CONFIG_BACKTRACE_SELF_TEST is not set
> +# CONFIG_RBTREE_TEST is not set
> +# CONFIG_ATOMIC64_SELFTEST is not set
> +# CONFIG_TEST_STRING_HELPERS is not set
> +# CONFIG_TEST_KSTRTOX is not set
> +# CONFIG_TEST_RHASHTABLE is not set
> +# CONFIG_DMA_API_DEBUG is not set
> +# CONFIG_TEST_FIRMWARE is not set
> +# CONFIG_TEST_UDELAY is not set
> +# CONFIG_SAMPLES is not set
> +CONFIG_HAVE_ARCH_KGDB=y
> +# CONFIG_KGDB is not set
> +# CONFIG_STRICT_DEVMEM is not set
> +# CONFIG_X86_VERBOSE_BOOTUP is not set
> +CONFIG_EARLY_PRINTK=y
> +# CONFIG_X86_PTDUMP is not set
> +CONFIG_DEBUG_RODATA=y
> +CONFIG_DEBUG_RODATA_TEST=y
> +CONFIG_DOUBLEFAULT=y
> +# CONFIG_DEBUG_TLBFLUSH is not set
> +# CONFIG_IOMMU_STRESS is not set
> +CONFIG_HAVE_MMIOTRACE_SUPPORT=y
> +CONFIG_IO_DELAY_TYPE_0X80=0
> +CONFIG_IO_DELAY_TYPE_0XED=1
> +CONFIG_IO_DELAY_TYPE_UDELAY=2
> +CONFIG_IO_DELAY_TYPE_NONE=3
> +CONFIG_IO_DELAY_0X80=y
> +# CONFIG_IO_DELAY_0XED is not set
> +# CONFIG_IO_DELAY_UDELAY is not set
> +# CONFIG_IO_DELAY_NONE is not set
> +CONFIG_DEFAULT_IO_DELAY_TYPE=0
> +# CONFIG_CPA_DEBUG is not set
> +# CONFIG_OPTIMIZE_INLINING is not set
> +# CONFIG_DEBUG_NMI_SELFTEST is not set
> +# CONFIG_X86_DEBUG_STATIC_CPU_HAS is not set
> +
> +#
> +# Security options
> +#
> +# CONFIG_KEYS is not set
> +# CONFIG_SECURITY_DMESG_RESTRICT is not set
> +# CONFIG_SECURITY is not set
> +# CONFIG_SECURITYFS is not set
> +CONFIG_DEFAULT_SECURITY_DAC=y
> +CONFIG_DEFAULT_SECURITY=""
> +CONFIG_CRYPTO=y
> +
> +#
> +# Crypto core or helper
> +#
> +CONFIG_CRYPTO_ALGAPI=y
> +CONFIG_CRYPTO_ALGAPI2=y
> +CONFIG_CRYPTO_AEAD2=y
> +CONFIG_CRYPTO_BLKCIPHER=y
> +CONFIG_CRYPTO_BLKCIPHER2=y
> +CONFIG_CRYPTO_HASH2=y
> +CONFIG_CRYPTO_RNG2=y
> +CONFIG_CRYPTO_PCOMP2=y
> +CONFIG_CRYPTO_MANAGER=y
> +CONFIG_CRYPTO_MANAGER2=y
> +# CONFIG_CRYPTO_USER is not set
> +# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
> +# CONFIG_CRYPTO_GF128MUL is not set
> +# CONFIG_CRYPTO_NULL is not set
> +# CONFIG_CRYPTO_PCRYPT is not set
> +CONFIG_CRYPTO_WORKQUEUE=y
> +# CONFIG_CRYPTO_CRYPTD is not set
> +# CONFIG_CRYPTO_AUTHENC is not set
> +
> +#
> +# Authenticated Encryption with Associated Data
> +#
> +# CONFIG_CRYPTO_CCM is not set
> +# CONFIG_CRYPTO_GCM is not set
> +# CONFIG_CRYPTO_SEQIV is not set
> +
> +#
> +# Block modes
> +#
> +CONFIG_CRYPTO_CBC=y
> +# CONFIG_CRYPTO_CTR is not set
> +# CONFIG_CRYPTO_CTS is not set
> +# CONFIG_CRYPTO_ECB is not set
> +# CONFIG_CRYPTO_LRW is not set
> +# CONFIG_CRYPTO_PCBC is not set
> +# CONFIG_CRYPTO_XTS is not set
> +
> +#
> +# Hash modes
> +#
> +# CONFIG_CRYPTO_CMAC is not set
> +# CONFIG_CRYPTO_HMAC is not set
> +# CONFIG_CRYPTO_XCBC is not set
> +# CONFIG_CRYPTO_VMAC is not set
> +
> +#
> +# Digest
> +#
> +# CONFIG_CRYPTO_CRC32C is not set
> +# CONFIG_CRYPTO_CRC32C_INTEL is not set
> +# CONFIG_CRYPTO_CRC32 is not set
> +# CONFIG_CRYPTO_CRC32_PCLMUL is not set
> +# CONFIG_CRYPTO_CRCT10DIF is not set
> +# CONFIG_CRYPTO_GHASH is not set
> +# CONFIG_CRYPTO_MD4 is not set
> +# CONFIG_CRYPTO_MD5 is not set
> +# CONFIG_CRYPTO_MICHAEL_MIC is not set
> +# CONFIG_CRYPTO_RMD128 is not set
> +# CONFIG_CRYPTO_RMD160 is not set
> +# CONFIG_CRYPTO_RMD256 is not set
> +# CONFIG_CRYPTO_RMD320 is not set
> +# CONFIG_CRYPTO_SHA1 is not set
> +# CONFIG_CRYPTO_SHA1_SSSE3 is not set
> +# CONFIG_CRYPTO_SHA256_SSSE3 is not set
> +# CONFIG_CRYPTO_SHA512_SSSE3 is not set
> +# CONFIG_CRYPTO_SHA256 is not set
> +# CONFIG_CRYPTO_SHA512 is not set
> +# CONFIG_CRYPTO_TGR192 is not set
> +# CONFIG_CRYPTO_WP512 is not set
> +# CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL is not set
> +
> +#
> +# Ciphers
> +#
> +CONFIG_CRYPTO_AES=y
> +# CONFIG_CRYPTO_AES_X86_64 is not set
> +# CONFIG_CRYPTO_AES_NI_INTEL is not set
> +# CONFIG_CRYPTO_ANUBIS is not set
> +# CONFIG_CRYPTO_ARC4 is not set
> +# CONFIG_CRYPTO_BLOWFISH is not set
> +# CONFIG_CRYPTO_BLOWFISH_X86_64 is not set
> +# CONFIG_CRYPTO_CAMELLIA is not set
> +# CONFIG_CRYPTO_CAMELLIA_X86_64 is not set
> +# CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64 is not set
> +# CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64 is not set
> +# CONFIG_CRYPTO_CAST5 is not set
> +# CONFIG_CRYPTO_CAST5_AVX_X86_64 is not set
> +# CONFIG_CRYPTO_CAST6 is not set
> +# CONFIG_CRYPTO_CAST6_AVX_X86_64 is not set
> +# CONFIG_CRYPTO_DES is not set
> +# CONFIG_CRYPTO_DES3_EDE_X86_64 is not set
> +# CONFIG_CRYPTO_FCRYPT is not set
> +# CONFIG_CRYPTO_KHAZAD is not set
> +# CONFIG_CRYPTO_SALSA20 is not set
> +# CONFIG_CRYPTO_SALSA20_X86_64 is not set
> +# CONFIG_CRYPTO_SEED is not set
> +# CONFIG_CRYPTO_SERPENT is not set
> +# CONFIG_CRYPTO_SERPENT_SSE2_X86_64 is not set
> +# CONFIG_CRYPTO_SERPENT_AVX_X86_64 is not set
> +# CONFIG_CRYPTO_SERPENT_AVX2_X86_64 is not set
> +# CONFIG_CRYPTO_TEA is not set
> +# CONFIG_CRYPTO_TWOFISH is not set
> +# CONFIG_CRYPTO_TWOFISH_X86_64 is not set
> +# CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set
> +# CONFIG_CRYPTO_TWOFISH_AVX_X86_64 is not set
> +
> +#
> +# Compression
> +#
> +# CONFIG_CRYPTO_DEFLATE is not set
> +# CONFIG_CRYPTO_ZLIB is not set
> +# CONFIG_CRYPTO_LZO is not set
> +# CONFIG_CRYPTO_LZ4 is not set
> +# CONFIG_CRYPTO_LZ4HC is not set
> +
> +#
> +# Random Number Generation
> +#
> +# CONFIG_CRYPTO_ANSI_CPRNG is not set
> +# CONFIG_CRYPTO_DRBG_MENU is not set
> +# CONFIG_CRYPTO_USER_API_HASH is not set
> +# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
> +# CONFIG_CRYPTO_HW is not set
> +CONFIG_HAVE_KVM=y
> +CONFIG_VIRTUALIZATION=y
> +# CONFIG_BINARY_PRINTF is not set
> +
> +#
> +# Library routines
> +#
> +CONFIG_BITREVERSE=y
> +CONFIG_GENERIC_STRNCPY_FROM_USER=y
> +CONFIG_GENERIC_STRNLEN_USER=y
> +CONFIG_GENERIC_NET_UTILS=y
> +CONFIG_GENERIC_FIND_FIRST_BIT=y
> +CONFIG_GENERIC_PCI_IOMAP=y
> +CONFIG_GENERIC_IOMAP=y
> +CONFIG_GENERIC_IO=y
> +CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
> +CONFIG_ARCH_HAS_FAST_MULTIPLIER=y
> +# CONFIG_CRC_CCITT is not set
> +# CONFIG_CRC16 is not set
> +# CONFIG_CRC_T10DIF is not set
> +# CONFIG_CRC_ITU_T is not set
> +CONFIG_CRC32=y
> +# CONFIG_CRC32_SELFTEST is not set
> +CONFIG_CRC32_SLICEBY8=y
> +# CONFIG_CRC32_SLICEBY4 is not set
> +# CONFIG_CRC32_SARWATE is not set
> +# CONFIG_CRC32_BIT is not set
> +# CONFIG_CRC7 is not set
> +# CONFIG_LIBCRC32C is not set
> +# CONFIG_CRC8 is not set
> +# CONFIG_AUDIT_ARCH_COMPAT_GENERIC is not set
> +# CONFIG_RANDOM32_SELFTEST is not set
> +CONFIG_ZLIB_INFLATE=y
> +CONFIG_LZO_DECOMPRESS=y
> +CONFIG_LZ4_DECOMPRESS=y
> +CONFIG_XZ_DEC=y
> +CONFIG_XZ_DEC_X86=y
> +CONFIG_XZ_DEC_POWERPC=y
> +CONFIG_XZ_DEC_IA64=y
> +CONFIG_XZ_DEC_ARM=y
> +CONFIG_XZ_DEC_ARMTHUMB=y
> +CONFIG_XZ_DEC_SPARC=y
> +CONFIG_XZ_DEC_BCJ=y
> +# CONFIG_XZ_DEC_TEST is not set
> +CONFIG_DECOMPRESS_GZIP=y
> +CONFIG_DECOMPRESS_BZIP2=y
> +CONFIG_DECOMPRESS_LZMA=y
> +CONFIG_DECOMPRESS_XZ=y
> +CONFIG_DECOMPRESS_LZO=y
> +CONFIG_DECOMPRESS_LZ4=y
> +CONFIG_HAS_IOMEM=y
> +CONFIG_HAS_IOPORT_MAP=y
> +CONFIG_HAS_DMA=y
> +CONFIG_CPU_RMAP=y
> +CONFIG_DQL=y
> +CONFIG_NLATTR=y
> +CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
> +# CONFIG_AVERAGE is not set
> +# CONFIG_CORDIC is not set
> +# CONFIG_DDR is not set
> +CONFIG_ARCH_HAS_SG_CHAIN=y
> --
> 1.8.5.5
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 3/7] linux-stubdomain: Build a disk image
2015-02-04 4:06 ` [RFC 3/7] linux-stubdomain: Build a disk image Eric Shelton
@ 2015-02-06 15:57 ` Stefano Stabellini
2015-02-06 17:45 ` Eric Shelton
0 siblings, 1 reply; 43+ messages in thread
From: Stefano Stabellini @ 2015-02-06 15:57 UTC (permalink / raw)
To: Eric Shelton; +Cc: anthony.perard, xen-devel, Ian.Campbell, stefano.stabellini
On Tue, 3 Feb 2015, Eric Shelton wrote:
> This patch builds a disk image intended to be mounted as rootfs by the
> Linux stub domain. It is assembled using dracut and genext2fs.
>
> Signed-off-by: Eric Shelton <eshelton@pobox.com>
> ---
> stubdom-linux/.gitignore | 4 ++
> stubdom-linux/Makefile | 45 +++++++++++++++++++-
> stubdom-linux/extra/initscript | 25 +++++++++++
> stubdom-linux/extra/qemu-ifup | 7 +++
> stubdom-linux/gen-stubdom-disk.sh | 89 +++++++++++++++++++++++++++++++++++++++
> 5 files changed, 168 insertions(+), 2 deletions(-)
> create mode 100644 stubdom-linux/extra/initscript
> create mode 100644 stubdom-linux/extra/qemu-ifup
> create mode 100755 stubdom-linux/gen-stubdom-disk.sh
>
> diff --git a/stubdom-linux/.gitignore b/stubdom-linux/.gitignore
> index 891f0c8..b8f2e26 100644
> --- a/stubdom-linux/.gitignore
> +++ b/stubdom-linux/.gitignore
> @@ -4,3 +4,7 @@
> /linux-*.tar.xz
> /linux-*/
> /vmlinuz-stubdom
> +/initramfs
> +/stubdom-disk.img
> +/dracut-???*
> +/genext2fs-*
> diff --git a/stubdom-linux/Makefile b/stubdom-linux/Makefile
> index 31bfbee..a46f5b0 100644
> --- a/stubdom-linux/Makefile
> +++ b/stubdom-linux/Makefile
> @@ -12,7 +12,19 @@ LINUX_V=linux-3.17.8
> VMLINUZ=$(LINUX_V)/arch/x86/boot/bzImage
> LINUX_URL=ftp://ftp.kernel.org/pub/linux/kernel/v3.x/$(LINUX_V).tar.xz
>
> -all: $(VMLINUZ)
> +DRACUT_URL="http://www.kernel.org/pub/linux/utils/boot/dracut"
> +DRACUT_V=dracut-033
> +
> +GENEXT2FS_V = 1.4.1
> +GENEXT2FS_URL="http://sourceforge.net/projects/genext2fs/files/genext2fs/$(GENEXT2FS_V)/genext2fs-$(GENEXT2FS_V).tar.gz/download"
I don't think that we need to download install these tools. They are
available on all major distros.
I think we could add them as dependency to the xen-unstable configure
script.
> +# Stubdom disk content
> +STUBDOM_DISK_FILE= \
> + qemu-build/i386-softmmu/qemu-system-i386 \
> + extra/initscript \
> + extra/qemu-ifup
> +
> +all: $(VMLINUZ) stubdom-disk.img
>
> qemu-build/Makefile:
> export GIT=$(GIT); \
> @@ -73,5 +85,34 @@ $(LINUX_V)/Makefile $(LINUX_V)/.config: $(LINUX_V).tar.xz
> $(VMLINUZ): $(LINUX_V)/.config
> $(MAKE) -C $(LINUX_V)
>
> -install: $(VMLINUZ)
> +$(DRACUT_V).tar.xz:
> + $(FETCHER) $@ $(DRACUT_URL)/$@
> +
> +DRACUT_INSTALL=$(CURDIR)/$(DRACUT_V)/dracut-install
> +$(DRACUT_INSTALL): $(DRACUT_V).tar.xz
> + tar xf $<
> + $(MAKE) -C $(DRACUT_V) dracut-install
> +
> +GENEXT2FS = $(shell which genext2fs 2>/dev/null)
> +ifeq ($(GENEXT2FS),)
> +GENEXT2FS = $(CURDIR)/genext2fs-$(GENEXT2FS_V)/genext2fs
> +endif
> +
> +genext2fs-$(GENEXT2FS_V).tar.gz:
> + $(FETCHER) $@ $(GENEXT2FS_URL)
> +$(CURDIR)/genext2fs-$(GENEXT2FS_V)/genext2fs: genext2fs-$(GENEXT2FS_V).tar.gz
> + tar xf $<
> + cd genext2fs-$(GENEXT2FS_V) && ./configure
> + $(MAKE) -C genext2fs-$(GENEXT2FS_V)
> +
> +gen-stubdom-disk.sh: $(DRACUT_INSTALL) $(GENEXT2FS)
> +
> +export DRACUT_INSTALL
> +export GENEXT2FS
> +stubdom-disk.img: gen-stubdom-disk.sh $(STUBDOM_DISK_FILE)
> + env -u MAKELEVEL -u MAKEFLAGS -u MFLAGS ./$<
> + chmod a-w $@
> +
> +install: $(VMLINUZ) stubdom-disk.img
> cp -f $(VMLINUZ) $(DESTDIR)/usr/local/lib/xen/boot/vmlinuz-stubdom
> + cp -f stubdom-disk.img $(DESTDIR)/usr/local/lib/xen/boot/
> diff --git a/stubdom-linux/extra/initscript b/stubdom-linux/extra/initscript
> new file mode 100644
> index 0000000..a0f50ad
> --- /dev/null
> +++ b/stubdom-linux/extra/initscript
> @@ -0,0 +1,25 @@
> +#!/bin/busybox sh
> +
> +set -e
> +set -x
> +mount -t sysfs /sys /sys
> +mount -t proc /proc /proc
> +mount -t xenfs -o nodev /proc/xen /proc/xen
> +
> +if test -e /sys/class/net/eth0; then
> + ip link set eth0 address fe:ff:ff:ff:ff:fe
> + ip addr flush eth0
> + ip link set eth0 up
> + brctl addbr br0
> + brctl addif br0 eth0
> + ip link set br0 up
> +else
> + echo "No network interface named eth0."
> + ls -l /sys/class/net/
> +fi
> +
> +domid=$(/bin/xenstore-read "target")
> +vm_path=$(xenstore-read "/local/domain/$domid/vm")
> +dm_args=$(xenstore-read "$vm_path/image/dmargs")
> +
> +/bin/qemu $dm_args
> diff --git a/stubdom-linux/extra/qemu-ifup b/stubdom-linux/extra/qemu-ifup
> new file mode 100644
> index 0000000..d71672b
> --- /dev/null
> +++ b/stubdom-linux/extra/qemu-ifup
> @@ -0,0 +1,7 @@
> +#! /bin/busybox sh
> +
> +ip link set "$1" down
> +ip link set "$1" address fe:ff:ff:ff:ff:fd
> +ip addr flush "$1"
> +brctl addif br0 "$1"
> +ip link set "$1" up
> diff --git a/stubdom-linux/gen-stubdom-disk.sh b/stubdom-linux/gen-stubdom-disk.sh
> new file mode 100755
> index 0000000..c209cba
> --- /dev/null
> +++ b/stubdom-linux/gen-stubdom-disk.sh
> @@ -0,0 +1,89 @@
> +#!/bin/bash
> +
> +set -e
> +umask 022
> +
> +script_qemu_ifup="extra/qemu-ifup"
> +script_init="extra/initscript"
> +
> +XEN_ROOT="$(cd ..; pwd)"
> +xenstore_libs="$XEN_ROOT/tools/xenstore"
> +libxc_libs="$XEN_ROOT/tools/libxc"
> +export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$xenstore_libs"
> +export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$libxc_libs"
> +
> +initdir="`pwd`/initramfs/"
> +
> +rm -fr "$initdir"
> +
> +# Using dracut to gather the shared libraries
> +# from https://dracut.wiki.kernel.org/index.php/Main_Page
> +if ! test -x "$DRACUT_INSTALL"; then
> + echo DRACUT_INSTALL unset or incorrect >&2
> + exit 1
> +fi
> +if ! test -x "$GENEXT2FS"; then
> + if ! which genext2fs 2>&1 >/dev/null; then
> + echo genext2fs not found and GENEXT2FS unset >&2
> + exit 1
> + fi
> +else
> + function genext2fs(){
> + "$GENEXT2FS" "$@"
> + }
> +fi
> +
> +
> +inst() {
> + [[ -e "${initdir}/${2:-$1}" ]] && return 0 # already there
> + "$DRACUT_INSTALL" -D "$initdir" -l "$@"
> +}
> +
> +mkdir -p "$initdir"/{bin,etc,proc/xen,sys,lib,dev,tmp}
> +
> +echo "Building initrd in $initdir"
> +inst busybox /bin/busybox
> +make DESTDIR="$initdir" -C qemu-build install
> +# this gather libs install on the system for qemu
> +inst "$initdir/bin/qemu-system-i386" /bin/qemu
> +inst "$XEN_ROOT/tools/xenstore/xenstore-read" "/bin/xenstore-read"
> +inst "$script_qemu_ifup" "/etc/qemu-ifup"
> +chmod +x "$initdir/etc/qemu-ifup"
> +inst "$script_init" "/init"
> +chmod 755 "$initdir/init"
> +
> +ln -s busybox "$initdir/bin/mount"
> +
> +for d in "/usr/lib" "$xenstore_libs" "$libxc_libs"; do
> + d="$initdir/$d"
> + if test -d "$d"; then
> + mv "$d"/* "$initdir/lib64/"
> + if test -L "$d"; then
> + rm "$d"
> + else
> + rmdir --ignore-fail-on-non-empty -p "$d"
> + fi
> + fi
> +done
> +
> +mv "$initdir/lib64/gcc"/*/*/* "$initdir/lib64/"
> +rm -rf "$initdir/lib64/gcc"
> +
> +mkdir -p "$initdir/usr"
> +ln -s /lib "$initdir/usr/lib"
> +
> +if false; then
> + IMAGE="./initramfs.cpio"
> + rm -f "$IMAGE"
> + (cd "$initdir"; find . | cpio -H newc --quiet -o) >| "$IMAGE" || exit 1
> + gzip -f "$IMAGE"
> +else # ext2 fs using:
> + stubdom_disk=stubdom-disk.img
> + rm -f "$stubdom_disk"
> + genext2fs \
> + --root "$initdir" \
> + --size-in-blocks $(($(du -s "$initdir"|cut -f1)+2000)) \
> + --reserved-percentage 0 \
> + --squash \
> + "$stubdom_disk"
> +fi
> --
> 1.8.5.5
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 4/7] libxl: Add "stubdomain_version" to domain_build_info.
2015-02-04 4:06 ` [RFC 4/7] libxl: Add "stubdomain_version" to domain_build_info Eric Shelton
@ 2015-02-06 16:06 ` Stefano Stabellini
2015-02-06 17:50 ` Eric Shelton
2015-02-09 9:11 ` Ian Campbell
1 sibling, 1 reply; 43+ messages in thread
From: Stefano Stabellini @ 2015-02-06 16:06 UTC (permalink / raw)
To: Eric Shelton; +Cc: anthony.perard, xen-devel, Ian.Campbell, stefano.stabellini
On Tue, 3 Feb 2015, Eric Shelton wrote:
> This enum gives the ability to select between a MiniOS-based QEMU
> traditional stub domain and a Linux-based QEMU upstream stub domain. To
> use the Linux-based stubdomain, the following two lines should be
> included in the appropriate xl.cfg file:
>
> device_model_version="qemu-xen"
> device_model_stubdomain_override=1
>
> To use the MiniOS-based stubdomain, the following is used instead:
>
> device_model_version="qemu-xen-traditional"
> device_model_stubdomain_override=1
>
> Signed-off-by: Eric Shelton <eshelton@pobox.com>
> ---
> tools/libxl/libxl_create.c | 34 +++++++++++++++++++++++++++++-----
> tools/libxl/libxl_types.idl | 7 +++++++
> 2 files changed, 36 insertions(+), 5 deletions(-)
>
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 98687bd..15258fa 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -181,12 +181,36 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
> }
>
> if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
> - b_info->device_model_version !=
> - LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
> libxl_defbool_val(b_info->device_model_stubdomain)) {
> - LIBXL__LOG(CTX, XTL_ERROR,
> - "device model stubdomains require \"qemu-xen-traditional\"");
> - return ERROR_INVAL;
> + if (!b_info->stubdomain_version) {
> + switch (b_info->device_model_version) {
> + case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
> + b_info->stubdomain_version = LIBXL_STUBDOMAIN_VERSION_MINIOS;
> + break;
> + case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> + b_info->stubdomain_version = LIBXL_STUBDOMAIN_VERSION_LINUX;
> + break;
> + default: abort();
> + }
> + }
> +
> + switch (b_info->device_model_version) {
> + case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
> + if (b_info->stubdomain_version != LIBXL_STUBDOMAIN_VERSION_MINIOS) {
> + LIBXL__LOG(CTX, XTL_ERROR,
> + "\"qemu-xen-traditional\" require \"minios\" as stubdomain");
> + return ERROR_INVAL;
> + }
> + break;
> + case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> + if (b_info->stubdomain_version != LIBXL_STUBDOMAIN_VERSION_LINUX) {
> + LIBXL__LOG(CTX, XTL_ERROR,
> + "\"qemu-xen\" require \"linux\" as stubdomain");
> + return ERROR_INVAL;
> + }
> + break;
> + default: abort();
> + }
> }
>
> if (!b_info->max_vcpus)
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 02be466..8d0ac3b 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -83,6 +83,12 @@ libxl_device_model_version = Enumeration("device_model_version", [
> (2, "QEMU_XEN"), # Upstream based qemu-xen device model
> ])
>
> +# Give the kernel running in the stub-domain
> +libxl_stubdomain_version = Enumeration("stubdomain_version", [
This should just be called stubdomain_version.
> + (1, "MINIOS"),
> + (2, "LINUX"),
> + ])
> +
> libxl_console_type = Enumeration("console_type", [
> (0, "UNKNOWN"),
> (1, "SERIAL"),
> @@ -379,6 +385,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>
> ("device_model_version", libxl_device_model_version),
> ("device_model_stubdomain", libxl_defbool),
> + ("stubdomain_version", libxl_stubdomain_version),
> # if you set device_model you must set device_model_version too
> ("device_model", string),
> ("device_model_ssidref", uint32),
> --
> 1.8.5.5
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 7/7] libxl: Wait for QEMU startup in stubdomain
2015-02-06 15:46 ` Eric Shelton
@ 2015-02-06 16:12 ` Wei Liu
0 siblings, 0 replies; 43+ messages in thread
From: Wei Liu @ 2015-02-06 16:12 UTC (permalink / raw)
To: Eric Shelton
Cc: Anthony PERARD, xen-devel, Wei Liu, Ian Campbell, Stefano Stabellini
On Fri, Feb 06, 2015 at 10:46:15AM -0500, Eric Shelton wrote:
> On Fri, Feb 6, 2015 at 9:59 AM, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Fri, Feb 06, 2015 at 08:56:40AM -0500, Eric Shelton wrote:
> >> On Fri, Feb 6, 2015 at 6:16 AM, Wei Liu <wei.liu2@citrix.com> wrote:
> >>
> >> I simply used the code already present in the QEMU upstream code,
> >> which is writing to that particular ath to indicate "running." Since
> >> it is distinct from the path used by the QEMU instance running in
> >> Dom0, it works for my intended purpose: ensuring the device model is
> >> running before unpausing the HVM guest. When you say it is "wrong,"
> >> is that just because you ultimately intend to rearchitect this and use
> >> something different? If so, maybe the path I am using is "good
> >> enough" until that happens. Otherwise, can you suggest a better path
> >> or mechanism?
> >>
> >
> > It is not "good enough". It just happens to be working.
> >
> > Currently the path is hardcoded "/local/domain/0/BLAH". It's wrong,
> > because the QEMU in stubdom is not running in 0. The correct prefix
> > should be "/local/domain/$stubdom_id".
>
> OK; that definitely makes more sense - I recall the same idea crossing
> my mind when I first dug into this. Although the revised protocol may
> go in a different direction, I will adopt this approach for now.
>
Sorry for not having explained this clearer in the first email. I can
keep you in the loop if you're interested.
> >> I noticed some discussion about this on xen-devel. Unfortunately, I
> >> was unable to find anything that laid out specifically what the
> >> problems are - can you point me to a bug report or such? The libxl
> >> startup code - with callbacks on top of callbacks, callbacks within
> >> callbacks, and callbacks stashed away in little places only to be
> >> called _much_ later - is really convoluted, I suspect particularly so
> >> for stubdom startup. I am not surprised it got broken - who can
> >> remember how it works?
> >>
> >
> > It's not how libxl is coded. It's the startup protocol that is broken.
> > The breakage of stubdom in Xen 4.5 is a latent bug exposed by a new
> > feature.
> >
> > I guess I should just send a bug report saying "Device model startup
> > protocol is broken". But I don't have much to say at this point, because
> > thorough research for both qemu-trad and qemu-upstream is required to
> > produce a sensible report.
>
> So, just where is the current protocol breaking down? Is there a
The hard part is there are already too many hardcoded /local/domain/0,
figuring out what needs to be /local/domain/$stubdom_id might take some
time. On the other hand, we have a chance to start with a clean slate
with upstream QEMU so it might not as hard as I think.
> contemplated bandaid for 4.5.1? I'm just trying to figure out what I
> might want to do differently.
>
Paul posted a bandaid patch today. It will be backported to 4.5.1 when
it is time.
<1423236389-10908-1-git-send-email-paul.durrant@citrix.com>
> > So prior to 4.5, when there is emulation request issued by a guest vcpu,
> > that request is put on a ring, guest vcpu is paused. When a DM shows up
> > it processes that request, posts response, then guest vcpu is unpaused.
> > So there is implicit dependency on Xen's behaviour for DM to work.
> >
> > In 4.5, a new feature called ioreq server is added. When Xen sees an
> > io request which no backing DM, it returns immediately. Guest sees some
> > wired value and crashes. That is, Xen's behaviour has changed and a
> > latent bug in stubdom's startup protocol is exposed.
>
> So, is the approach that I took - waiting for the stubdom DM to finish
> initializing - a reasonable short-term solution? I guess I am
The idea is certainly valid.
> wondering whether the fix you are contemplating is in libxl, the
> hypervisor, or both.
>
It would mostly be in toolstack and QEMU.
Regardless of this protocol fix, there is still other stuffs like frame
buffer plumbing that awaits to be done. So as Stefano said if you can get
those upstreamed in QEMU that would be great.
Wei.
> Thanks,
> Eric
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 5/7] libxl: Handle Linux stubdomain specific QEMU options.
2015-02-04 4:06 ` [RFC 5/7] libxl: Handle Linux stubdomain specific QEMU options Eric Shelton
@ 2015-02-06 16:17 ` Stefano Stabellini
0 siblings, 0 replies; 43+ messages in thread
From: Stefano Stabellini @ 2015-02-06 16:17 UTC (permalink / raw)
To: Eric Shelton; +Cc: anthony.perard, xen-devel, Ian.Campbell, stefano.stabellini
On Tue, 3 Feb 2015, Eric Shelton wrote:
> This patch creates an appropriate command line for the QEMU instance
> running in a Linux-based stubdomain.
>
> NOTE: a number of items are not currently implemented for Linux-based
> stubdomains, such as:
> - save/restore
> - QMP socket
> - graphics output (e.g., VNC)
>
> Signed-off-by: Eric Shelton <eshelton@pobox.com>
> ---
> tools/libxl/libxl_dm.c | 86 ++++++++++++++++++++++++++++++++++----------------
> 1 file changed, 58 insertions(+), 28 deletions(-)
>
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 8599a6a..68d5886 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -20,9 +20,12 @@
> #include "libxl_internal.h"
> #include <xen/hvm/e820.h>
>
> -static const char *libxl_tapif_script(libxl__gc *gc)
> +static const char *libxl_tapif_script(libxl__gc *gc,
> + const libxl_domain_build_info *info)
> {
> #if defined(__linux__) || defined(__FreeBSD__)
> + if (info->stubdomain_version == LIBXL_STUBDOMAIN_VERSION_LINUX)
> + return libxl__sprintf(gc, "/etc/qemu-ifup");
> return libxl__strdup(gc, "no");
> #else
> return libxl__sprintf(gc, "%s/qemu-ifup", libxl__xen_script_dir_path());
> @@ -307,8 +310,8 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
> "tap,vlan=%d,ifname=%s,bridge=%s,"
> "script=%s,downscript=%s",
> nics[i].devid, ifname, nics[i].bridge,
> - libxl_tapif_script(gc),
> - libxl_tapif_script(gc)),
> + libxl_tapif_script(gc, b_info),
> + libxl_tapif_script(gc, b_info)),
> NULL);
> ioemu_nics++;
> }
> @@ -430,6 +433,7 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> int i, connection, devid;
> uint64_t ram_size;
> const char *path, *chardev;
> + bool is_stubdom = libxl_defbool_val(b_info->device_model_stubdomain);
>
> dm_args = flexarray_make(gc, 16, 1);
>
> @@ -437,15 +441,18 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> "-xen-domid",
> libxl__sprintf(gc, "%d", guest_domid), NULL);
>
> - flexarray_append(dm_args, "-chardev");
> - flexarray_append(dm_args,
> - libxl__sprintf(gc, "socket,id=libxl-cmd,"
> - "path=%s/qmp-libxl-%d,server,nowait",
> - libxl__run_dir_path(), guest_domid));
> -
> - flexarray_append(dm_args, "-no-shutdown");
> - flexarray_append(dm_args, "-mon");
> - flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
> + /* There is currently no way to access the QMP socket in the stubdom */
> + if (!is_stubdom) {
> + flexarray_append(dm_args, "-chardev");
> + flexarray_append(dm_args,
> + libxl__sprintf(gc, "socket,id=libxl-cmd,"
> + "path=%s/qmp-libxl-%d,server,nowait",
> + libxl__run_dir_path(), guest_domid));
> +
> + flexarray_append(dm_args, "-no-shutdown");
> + flexarray_append(dm_args, "-mon");
> + flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
> + }
>
> for (i = 0; i < guest_config->num_channels; i++) {
> connection = guest_config->channels[i].connection;
> @@ -483,7 +490,7 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> flexarray_vappend(dm_args, "-name", c_info->name, NULL);
> }
>
> - if (vnc) {
> + if (vnc && !is_stubdom) {
> char *vncarg = NULL;
>
> flexarray_append(dm_args, "-vnc");
> @@ -524,7 +531,7 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> flexarray_append(dm_args, vncarg);
> }
>
> - if (sdl) {
> + if (sdl && !is_stubdom) {
> flexarray_append(dm_args, "-sdl");
> /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
> }
> @@ -552,10 +559,19 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> return NULL;
> }
> if (b_info->u.hvm.serial) {
> - flexarray_vappend(dm_args,
> - "-serial", b_info->u.hvm.serial, NULL);
> + if (is_stubdom) {
> + flexarray_vappend(dm_args,
> + "-serial", "/dev/hvc1", NULL);
> + } else {
> + flexarray_vappend(dm_args,
> + "-serial", b_info->u.hvm.serial, NULL);
> + }
> } else if (b_info->u.hvm.serial_list) {
> char **p;
> + if (is_stubdom) {
> + flexarray_vappend(dm_args,
> + "-serial", "/dev/hvc1", NULL);
> + }
> for (p = b_info->u.hvm.serial_list;
> *p;
> p++) {
> @@ -570,7 +586,7 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> flexarray_append(dm_args, "-nographic");
> }
>
> - if (libxl_defbool_val(b_info->u.hvm.spice.enable)) {
> + if (libxl_defbool_val(b_info->u.hvm.spice.enable) && !is_stubdom) {
> const libxl_spice_info *spice = &b_info->u.hvm.spice;
> char *spiceoptions = dm_spice_options(gc, spice);
> if (!spiceoptions)
> @@ -700,8 +716,8 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> "type=tap,id=net%d,ifname=%s,"
> "script=%s,downscript=%s",
> nics[i].devid, ifname,
> - libxl_tapif_script(gc),
> - libxl_tapif_script(gc)));
> + libxl_tapif_script(gc, b_info),
> + libxl_tapif_script(gc, b_info)));
> ioemu_nics++;
> }
> }
> @@ -789,6 +805,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> drive = libxl__sprintf
> (gc, "if=ide,index=%d,media=cdrom,cache=writeback,id=ide-%i",
> disk, dev_number);
> + else if (b_info->stubdomain_version == LIBXL_STUBDOMAIN_VERSION_LINUX)
> + drive = libxl__sprintf
> + (gc, "file=%s,if=ide,index=%d,media=cdrom,cache=writeback,format=%s,id=ide-%i",
> + "/dev/xvdc", disk, "host_cdrom", dev_number);
> else
> drive = libxl__sprintf
> (gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s,cache=writeback,id=ide-%i",
> @@ -824,10 +844,16 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> drive = libxl__sprintf
> (gc, "file=%s,if=scsi,bus=0,unit=%d,format=%s,cache=writeback",
> pdev_path, disk, format);
> - else if (disk < 4)
> - drive = libxl__sprintf
> - (gc, "file=%s,if=ide,index=%d,media=disk,format=%s,cache=writeback",
> - pdev_path, disk, format);
> + else if (disk < 4) {
> + if (b_info->stubdomain_version == LIBXL_STUBDOMAIN_VERSION_LINUX)
> + drive = libxl__sprintf
> + (gc, "file=%s,if=ide,index=%d,media=disk,cache=writeback,format=%s",
> + "/dev/xvda", disk, "host_device");
> + else
> + drive = libxl__sprintf
> + (gc, "file=%s,if=ide,index=%d,media=disk,format=%s,cache=writeback",
> + pdev_path, disk, format);
> + }
> else
> continue; /* Do not emulate this disk */
> }
I don't think that this works if you specify more than one disk or one
cdrom for the guest.
> @@ -854,7 +880,7 @@ static char ** libxl__build_device_model_args(libxl__gc *gc,
> const libxl_domain_config *guest_config,
> const libxl__domain_build_state *state,
> int *dm_state_fd)
> -/* dm_state_fd may be NULL iff caller knows we are using old stubdom
> +/* dm_state_fd may be NULL iff caller knows we are using stubdom
> * and therefore will be passing a filename rather than a fd. */
> {
> libxl_ctx *ctx = libxl__gc_owner(gc);
> @@ -865,8 +891,10 @@ static char ** libxl__build_device_model_args(libxl__gc *gc,
> guest_domid, guest_config,
> state);
> case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> - assert(dm_state_fd != NULL);
> - assert(*dm_state_fd < 0);
> + if (!libxl_defbool_val(guest_config->b_info.device_model_stubdomain)) {
> + assert(dm_state_fd != NULL);
> + assert(*dm_state_fd < 0);
> + }
> return libxl__build_device_model_args_new(gc, dm,
> guest_domid, guest_config,
> state, dm_state_fd);
> @@ -922,7 +950,7 @@ static int libxl__vfb_and_vkb_from_hvm_guest_config(libxl__gc *gc,
>
> static int libxl__write_stub_dmargs(libxl__gc *gc,
> int dm_domid, int guest_domid,
> - char **args)
> + char **args, bool linux_stubdom)
I don't see the corresponding change to the call sites.
> {
> libxl_ctx *ctx = libxl__gc_owner(gc);
> int i;
> @@ -950,7 +978,9 @@ static int libxl__write_stub_dmargs(libxl__gc *gc,
> i = 1;
> dmargs[0] = '\0';
> while (args[i] != NULL) {
> - if (strcmp(args[i], "-sdl") && strcmp(args[i], "-M") && strcmp(args[i], "xenfv")) {
> + if (linux_stubdom ||
> + (strcmp(args[i], "-sdl") &&
> + strcmp(args[i], "-M") && strcmp(args[i], "xenfv"))) {
You are always passing all the args to QEMU, without filters. Why?
Is that because you have filtered the arguments previously?
If so, could not just do the same for qemu-xen-tradition case and unify
the code paths?
> strcat(dmargs, " ");
> strcat(dmargs, args[i]);
> }
> --
> 1.8.5.5
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 6/7] libxl: Build the domain with a Linux based stubdomain
2015-02-04 4:06 ` [RFC 6/7] libxl: Build the domain with a Linux based stubdomain Eric Shelton
@ 2015-02-06 16:33 ` Stefano Stabellini
0 siblings, 0 replies; 43+ messages in thread
From: Stefano Stabellini @ 2015-02-06 16:33 UTC (permalink / raw)
To: Eric Shelton; +Cc: anthony.perard, xen-devel, Ian.Campbell, stefano.stabellini
On Tue, 3 Feb 2015, Eric Shelton wrote:
> This will build a Linux-based stubdomain with QEMU upstream.
>
> Signed-off-by: Eric Shelton <eshelton@pobox.com>
> ---
> tools/libxl/libxl.c | 25 ++++++++--
> tools/libxl/libxl_create.c | 7 ++-
> tools/libxl/libxl_dm.c | 108 ++++++++++++++++++++++++++++++++++++-------
> tools/libxl/libxl_internal.c | 22 +++++++++
> tools/libxl/libxl_internal.h | 4 ++
> 5 files changed, 145 insertions(+), 21 deletions(-)
>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 82227e8..85cf5eb 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -1757,8 +1757,17 @@ static int libxl__primary_console_find(libxl_ctx *ctx, uint32_t domid_vm,
>
> if (stubdomid) {
> *domid = stubdomid;
> - *cons_num = STUBDOM_CONSOLE_SERIAL;
> *type = LIBXL_CONSOLE_TYPE_PV;
> + switch (libxl__stubdomain_version_running(gc, stubdomid)) {
> + case LIBXL_STUBDOMAIN_VERSION_MINIOS:
> + *cons_num = STUBDOM_CONSOLE_SERIAL;
> + break;
> + case LIBXL_STUBDOMAIN_VERSION_LINUX:
> + *cons_num = 1;
You might want to introduce LINUX_STUBDOMAIN_CONSOLE_SERIAL and rename
the existing to MINIOS_STUBDOM_CONSOLE_SERIAL.
In any case I think you'll eventually want as many serial console in a
linux stubdom as you have in a minios stubdom.
> + break;
> + default:
> + abort();
> + }
> } else {
> switch (libxl__domain_type(gc, domid_vm)) {
> case LIBXL_DOMAIN_TYPE_HVM:
> @@ -4927,8 +4936,18 @@ int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
> switch (b_info->type) {
> case LIBXL_DOMAIN_TYPE_HVM:
> *need_memkb += b_info->shadow_memkb + LIBXL_HVM_EXTRA_MEMORY;
> - if (libxl_defbool_val(b_info->device_model_stubdomain))
> - *need_memkb += 32 * 1024;
> + if (libxl_defbool_val(b_info->device_model_stubdomain)) {
> + switch (b_info->stubdomain_version) {
> + case LIBXL_STUBDOMAIN_VERSION_MINIOS:
> + *need_memkb += 32 * 1024;
> + break;
> + case LIBXL_STUBDOMAIN_VERSION_LINUX:
> + *need_memkb += LIBXL_LINUX_STUBDOM_MEM * 1024;
> + break;
> + default:
> + abort();
> + }
> + }
> break;
> case LIBXL_DOMAIN_TYPE_PV:
> *need_memkb += b_info->shadow_memkb + LIBXL_PV_EXTRA_MEMORY;
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 15258fa..b2c903e 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -1358,7 +1358,12 @@ static void domcreate_devmodel_started(libxl__egc *egc,
> if (dcs->dmss.dm.guest_domid) {
> if (d_config->b_info.device_model_version
> == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
> - libxl__qmp_initializations(gc, domid, d_config);
> + if (!libxl_defbool_val(d_config->b_info.device_model_stubdomain)) {
> + libxl__qmp_initializations(gc, domid, d_config);
> + } else {
> + int stubdom_domid = dcs->dmss.pvqemu.guest_domid;
> + libxl__qmp_initializations(gc, stubdom_domid, d_config);
> + }
> }
> }
>
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 68d5886..d03be4a 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -1000,6 +1000,16 @@ retry_transaction:
> return 0;
> }
>
> +static int libxl__store_libxl_entry(libxl__gc *gc, uint32_t domid,
> + const char *name, const char *value)
> +{
> + char *path = NULL;
> +
> + path = libxl__xs_libxl_path(gc, domid);
> + path = libxl__sprintf(gc, "%s/%s", path, name);
> + return libxl__xs_write(gc, XBT_NULL, path, "%s", value);
> +}
> +
> static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
> libxl__dm_spawn_state *stubdom_dmss,
> int rc);
> @@ -1030,6 +1040,7 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
> char **args;
> struct xs_permissions perm[2];
> xs_transaction_t t;
> + libxl_device_disk disk_stub;
>
> /* convenience aliases */
> libxl_domain_config *const dm_config = &sdss->dm_config;
> @@ -1038,10 +1049,14 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
> libxl__domain_build_state *const d_state = sdss->dm.build_state;
> libxl__domain_build_state *const stubdom_state = &sdss->dm_state;
>
> - if (guest_config->b_info.device_model_version !=
> - LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
> - ret = ERROR_INVAL;
> - goto out;
> + assert(libxl_defbool_val(guest_config->b_info.device_model_stubdomain));
> +
> + if (guest_config->b_info.stubdomain_version == LIBXL_STUBDOMAIN_VERSION_LINUX) {
> + if (d_state->saved_state) {
> + LOG(ERROR, "Save/Restore not supported yet with Linux Stubdom.");
> + ret = -1;
> + goto out;
> + }
> }
>
> sdss->pvqemu.guest_domid = 0;
> @@ -1062,7 +1077,16 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
> libxl_domain_build_info_init_type(&dm_config->b_info, LIBXL_DOMAIN_TYPE_PV);
>
> dm_config->b_info.max_vcpus = 1;
> - dm_config->b_info.max_memkb = 32 * 1024;
> + switch (guest_config->b_info.stubdomain_version) {
> + case LIBXL_STUBDOMAIN_VERSION_MINIOS:
> + dm_config->b_info.max_memkb = 32 * 1024;
> + break;
> + case LIBXL_STUBDOMAIN_VERSION_LINUX:
> + dm_config->b_info.max_memkb = LIBXL_LINUX_STUBDOM_MEM * 1024;
> + break;
> + default:
> + abort();
> + }
> dm_config->b_info.target_memkb = dm_config->b_info.max_memkb;
>
> dm_config->b_info.u.pv.features = "";
> @@ -1096,10 +1120,32 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
> dm_config->vkbs = vkb;
> dm_config->num_vkbs = 1;
>
> - stubdom_state->pv_kernel.path
> - = libxl__abs_path(gc, "ioemu-stubdom.gz", libxl__xenfirmwaredir_path());
> - stubdom_state->pv_cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
> - stubdom_state->pv_ramdisk.path = "";
> + switch (guest_config->b_info.stubdomain_version) {
> + case LIBXL_STUBDOMAIN_VERSION_MINIOS:
> + stubdom_state->pv_kernel.path
> + = libxl__abs_path(gc, "ioemu-stubdom.gz", libxl__xenfirmwaredir_path());
> + stubdom_state->pv_cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
> + stubdom_state->pv_ramdisk.path = "";
> + break;
> + case LIBXL_STUBDOMAIN_VERSION_LINUX:
> + libxl_device_disk_init(&disk_stub);
> + disk_stub.readwrite = 0;
> + disk_stub.format = LIBXL_DISK_FORMAT_RAW;
> + disk_stub.is_cdrom = 0;
> + disk_stub.vdev = "xvdz";
I think that we need a way to translate guest disks into xvd? devices
within the linux stubdom. The function could also check if we have name
clashing with the stubdom own disk.
> + disk_stub.pdev_path = libxl__abs_path(gc, "stubdom-disk.img",
> + libxl__xenfirmwaredir_path());
> + ret = libxl__device_disk_setdefault(gc, &disk_stub);
> + if (ret) goto out;
> + stubdom_state->pv_kernel.path
> + = libxl__abs_path(gc, "vmlinuz-stubdom", libxl__xenfirmwaredir_path());
> + stubdom_state->pv_cmdline
> + = "debug console=hvc0 root=/dev/xvdz ro init=/init";
> + stubdom_state->pv_ramdisk.path = "";
> + break;
> + default:
> + abort();
> + }
>
> /* fixme: this function can leak the stubdom if it fails */
> ret = libxl__domain_make(gc, &dm_config->c_info, &sdss->pvqemu.guest_domid);
> @@ -1117,7 +1163,12 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
> goto out;
> }
>
> - libxl__write_stub_dmargs(gc, dm_domid, guest_domid, args);
> + libxl__store_libxl_entry(gc, guest_domid, "dm-version",
> + libxl_device_model_version_to_string(dm_config->b_info.device_model_version));
> + libxl__store_libxl_entry(gc, dm_domid, "stubdom-version",
> + libxl_stubdomain_version_to_string(guest_config->b_info.stubdomain_version));
> + libxl__write_stub_dmargs(gc, dm_domid, guest_domid, args,
> + guest_config->b_info.stubdomain_version == LIBXL_STUBDOMAIN_VERSION_LINUX);
> libxl__xs_write(gc, XBT_NULL,
> libxl__sprintf(gc, "%s/image/device-model-domid",
> libxl__xs_get_dompath(gc, guest_domid)),
> @@ -1126,6 +1177,15 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
> libxl__sprintf(gc, "%s/target",
> libxl__xs_get_dompath(gc, dm_domid)),
> "%d", guest_domid);
> + if (guest_config->b_info.stubdomain_version == LIBXL_STUBDOMAIN_VERSION_LINUX) {
> + /* qemu-xen is used as a dm in the stubdomain, so we set the bios
> + * accroding to this */
> + libxl__xs_write(gc, XBT_NULL,
> + libxl__sprintf(gc, "%s/hvmloader/bios",
> + libxl__xs_get_dompath(gc, guest_domid)),
> + "%s",
> + libxl_bios_type_to_string(LIBXL_BIOS_TYPE_SEABIOS));
Why is this QEMU upstream specific?
> + }
> ret = xc_domain_set_target(ctx->xch, dm_domid, guest_domid);
> if (ret<0) {
> LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> @@ -1153,6 +1213,10 @@ retry_transaction:
>
> libxl__multidev_begin(ao, &sdss->multidev);
> sdss->multidev.callback = spawn_stub_launch_dm;
> + if (guest_config->b_info.stubdomain_version == LIBXL_STUBDOMAIN_VERSION_LINUX) {
> + libxl__ao_device *aodev = libxl__multidev_prepare(&sdss->multidev);
> + libxl__device_disk_add(egc, dm_domid, &disk_stub, aodev);
> + }
> libxl__add_disks(egc, ao, dm_domid, dm_config, &sdss->multidev);
> libxl__multidev_prepared(egc, &sdss->multidev, 0);
>
> @@ -1201,6 +1265,10 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
> if (ret)
> goto out;
>
> + if (guest_config->b_info.stubdomain_version == LIBXL_STUBDOMAIN_VERSION_LINUX) {
> + /* no special console for save/restore, only the logging console */
> + num_console = 1;
> + }
> if (guest_config->b_info.u.hvm.serial)
> num_console++;
>
> @@ -1229,14 +1297,20 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
> free(filename);
> break;
> case STUBDOM_CONSOLE_SAVE:
> - console[i].output = libxl__sprintf(gc, "file:%s",
> - libxl__device_model_savefile(gc, guest_domid));
> - break;
> + if (guest_config->b_info.stubdomain_version
> + == LIBXL_STUBDOMAIN_VERSION_MINIOS) {
> + console[i].output = libxl__sprintf(gc, "file:%s",
> + libxl__device_model_savefile(gc, guest_domid));
> + break;
> + }
> case STUBDOM_CONSOLE_RESTORE:
> - if (d_state->saved_state)
> - console[i].output =
> - libxl__sprintf(gc, "pipe:%s", d_state->saved_state);
> - break;
> + if (guest_config->b_info.stubdomain_version
> + == LIBXL_STUBDOMAIN_VERSION_MINIOS) {
> + if (d_state->saved_state)
> + console[i].output =
> + libxl__sprintf(gc, "pipe:%s", d_state->saved_state);
> + break;
> + }
> default:
> console[i].output = "pty";
> break;
> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
> index ddc68ab..d38e23d 100644
> --- a/tools/libxl/libxl_internal.c
> +++ b/tools/libxl/libxl_internal.c
> @@ -364,6 +364,28 @@ int libxl__device_model_version_running(libxl__gc *gc, uint32_t domid)
> return value;
> }
>
> +int libxl__stubdomain_version_running(libxl__gc *gc, uint32_t domid)
> +{
> + char *path = NULL;
> + char *stub_version = NULL;
> + libxl_stubdomain_version value;
> +
> + path = libxl__xs_libxl_path(gc, domid);
> + path = libxl__sprintf(gc, "%s/stubdom-version", path);
> + stub_version = libxl__xs_read(gc, XBT_NULL, path);
> + if (!stub_version) {
> + return LIBXL_STUBDOMAIN_VERSION_MINIOS;
> + }
> +
> + if (libxl_stubdomain_version_from_string(stub_version, &value) < 0) {
> + libxl_ctx *ctx = libxl__gc_owner(gc);
> + LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> + "fatal: %s contain a wrong value (%s)", path, stub_version);
> + return -1;
> + }
> + return value;
> +}
> +
> int libxl__hotplug_settings(libxl__gc *gc, xs_transaction_t t)
> {
> int rc = 0;
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 934465a..8755022 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -102,6 +102,7 @@
> #define STUBDOM_CONSOLE_RESTORE 2
> #define STUBDOM_CONSOLE_SERIAL 3
> #define STUBDOM_SPECIAL_CONSOLES 3
> +#define LIBXL_LINUX_STUBDOM_MEM 128
> #define TAP_DEVICE_SUFFIX "-emu"
> #define DISABLE_UDEV_PATH "libxl/disable_udev"
> #define DOMID_XS_PATH "domid"
> @@ -1794,6 +1795,9 @@ _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc_opt, const char *s);
> _hidden int libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
> /* Return the system-wide default device model */
> _hidden libxl_device_model_version libxl__default_device_model(libxl__gc *gc);
> + /* Based on /libxl/$domid/stubdom-version xenstore key
> + * default is minios */
> +_hidden int libxl__stubdomain_version_running(libxl__gc *gc, uint32_t domid);
>
> /* Check how executes hotplug script currently */
> int libxl__hotplug_settings(libxl__gc *gc, xs_transaction_t t);
> --
> 1.8.5.5
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 7/7] libxl: Wait for QEMU startup in stubdomain
2015-02-06 15:36 ` Stefano Stabellini
@ 2015-02-06 17:10 ` Eric Shelton
2015-02-06 17:23 ` Stefano Stabellini
0 siblings, 1 reply; 43+ messages in thread
From: Eric Shelton @ 2015-02-06 17:10 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Anthony PERARD, xen-devel, Wei Liu, Ian Campbell
On Fri, Feb 6, 2015 at 10:36 AM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Fri, 6 Feb 2015, Wei Liu wrote:
>> ISTR our policy is upstream first. That is, though we maintain our own
>> qemu tree those changesets are all upstream changesets. Arguably there
>> might be some bandaid changesets that are not upstream but big changes
>> like this needs to be upstreamed first.
>>
>> Stefano, could you clarify this and correct me if I'm wrong?
>
> Yes, the policy is upstream first, however it doesn't need to land in a
> QEMU release. Just be upstream.
>
> There is still please of time for that: Eric just needs to send his
> patches to qemu-devel, get the acks, and I'll apply to
> qemu-xen-upstream.
Sounds good. I think the main thing I am looking at before going to
qemu-devel is getting the xenfb-based display code up and running.
However, QEMU is a somewhat unfamiliar codebase for me, and it doesn't
help that QEMU's display pipeline seems to have been rearchitected a
time or two since QEMU 0.10, as it seems to limit QEMU-traditional's
utility as a prototype to follow. If anyone was any ideas what the
missing links are for the display pipeline, I would appreciate any
pointers.
>> > > So my hunch is that we're not going to make it in time for
>> > > 4.6. :-/
>> > >
>> > > Wei.
>> >
>> > 4.5 was _just_ released, and Xen is on a ~10 month release cycle. Why
>> > can't this get done? Someone just has to take a little time to sit
>>
>> Notably there are many months that are code freeze.
>>
>> And due to our upstream first QEMU policy we would also need to upstream
>> changes to QEMU.
>
> Getting the patches upstream in QEMU shouldn't take longer than getting
> them upstream in Xen.
>
> Also I think upstream QEMU stubdoms would be valuable even without
> save/restore support.
Good to hear. As I mentioned when I posted the patches, I am guessing
QMP, which appears to be needed for save/restore among other things,
is going to present some headaches if there are any commands that will
require coordination of both the stubdom- and Dom0-side instances of
QEMU for completion. Anyway, I doubt I am the right person to tackle
save/restore - it's not a feature I make use of at all.
>> > Can we arrive at an agreement that a Linux-based QEMU-upstream stubdom
>> > should _at least_ be a technical preview for Xen 4.6? A year ago,
>
> I agree. Or rumpkernel-based QEMU-upstream stubdom. Or something.
>> If we really want to make this happen before new protocol and
>> implementation are in place. That would be "tech preview" or
>> "experimental", whichever is the term for least mature technology. Note
>> that this is not due to the route it chooses (Linux based), it's due to
>> the fact that the protocol is broken and destined to be changed.
>
> I think we should not block the entire upstream stubdom effort, whether
> it is Linux, MiniOS or Rumpkernel based, waiting for the bootup protocol
> to be fixed.
>
> The two things can and should be done in parallel.
Great; I think we should be able to make this happen for 4.6.
One of the main issues outstanding from when Anthony originally posted
his patches is how we want to go about building this? I honestly do
not know how well the current dracut-based approach to building the
root image will work across various Linux distributions; perhaps it
will be OK, since all of the libraries that dracut will siphon in will
have to be in place to meet the build requirements for QEMU to begin
with. However, I have zero knowledge about ARM-based Xen or where
NetBSD is used for dom0, and how they might affect the decisionmaking.
I also do not know what lessons have been learned from building other
stubdoms, rumpkernel, or Mirage that might inform these decisions.
In other words, what do you see as a sensible build scheme? The
approach taken in the patches strikes me as too hacky for release
quality, but maybe it is OK...
- Eric
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 7/7] libxl: Wait for QEMU startup in stubdomain
2015-02-06 17:10 ` Eric Shelton
@ 2015-02-06 17:23 ` Stefano Stabellini
2015-02-09 9:07 ` Ian Campbell
0 siblings, 1 reply; 43+ messages in thread
From: Stefano Stabellini @ 2015-02-06 17:23 UTC (permalink / raw)
To: Eric Shelton
Cc: xen-devel, Wei Liu, Ian Campbell, Stefano Stabellini,
Ian Jackson, Anthony PERARD
On Fri, 6 Feb 2015, Eric Shelton wrote:
> On Fri, Feb 6, 2015 at 10:36 AM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Fri, 6 Feb 2015, Wei Liu wrote:
>
> >> ISTR our policy is upstream first. That is, though we maintain our own
> >> qemu tree those changesets are all upstream changesets. Arguably there
> >> might be some bandaid changesets that are not upstream but big changes
> >> like this needs to be upstreamed first.
> >>
> >> Stefano, could you clarify this and correct me if I'm wrong?
> >
> > Yes, the policy is upstream first, however it doesn't need to land in a
> > QEMU release. Just be upstream.
> >
> > There is still please of time for that: Eric just needs to send his
> > patches to qemu-devel, get the acks, and I'll apply to
> > qemu-xen-upstream.
>
> Sounds good. I think the main thing I am looking at before going to
> qemu-devel is getting the xenfb-based display code up and running.
> However, QEMU is a somewhat unfamiliar codebase for me, and it doesn't
> help that QEMU's display pipeline seems to have been rearchitected a
> time or two since QEMU 0.10, as it seems to limit QEMU-traditional's
> utility as a prototype to follow. If anyone was any ideas what the
> missing links are for the display pipeline, I would appreciate any
> pointers.
Firstly I would check that xenfb is working without QEMU.
Then I would try to get access to QEMU to the framebuffer using
something like directfb:
https://lists.gnu.org/archive/html/qemu-devel/2010-05/msg01201.html
Or the directfb driver in libsdl.
> >> > > So my hunch is that we're not going to make it in time for
> >> > > 4.6. :-/
> >> > >
> >> > > Wei.
> >> >
> >> > 4.5 was _just_ released, and Xen is on a ~10 month release cycle. Why
> >> > can't this get done? Someone just has to take a little time to sit
> >>
> >> Notably there are many months that are code freeze.
> >>
> >> And due to our upstream first QEMU policy we would also need to upstream
> >> changes to QEMU.
> >
> > Getting the patches upstream in QEMU shouldn't take longer than getting
> > them upstream in Xen.
> >
> > Also I think upstream QEMU stubdoms would be valuable even without
> > save/restore support.
>
> Good to hear. As I mentioned when I posted the patches, I am guessing
> QMP, which appears to be needed for save/restore among other things,
> is going to present some headaches if there are any commands that will
> require coordination of both the stubdom- and Dom0-side instances of
> QEMU for completion. Anyway, I doubt I am the right person to tackle
> save/restore - it's not a feature I make use of at all.
fair enough
> >> > Can we arrive at an agreement that a Linux-based QEMU-upstream stubdom
> >> > should _at least_ be a technical preview for Xen 4.6? A year ago,
> >
> > I agree. Or rumpkernel-based QEMU-upstream stubdom. Or something.
>
> >> If we really want to make this happen before new protocol and
> >> implementation are in place. That would be "tech preview" or
> >> "experimental", whichever is the term for least mature technology. Note
> >> that this is not due to the route it chooses (Linux based), it's due to
> >> the fact that the protocol is broken and destined to be changed.
> >
> > I think we should not block the entire upstream stubdom effort, whether
> > it is Linux, MiniOS or Rumpkernel based, waiting for the bootup protocol
> > to be fixed.
> >
> > The two things can and should be done in parallel.
>
> Great; I think we should be able to make this happen for 4.6.
>
> One of the main issues outstanding from when Anthony originally posted
> his patches is how we want to go about building this? I honestly do
> not know how well the current dracut-based approach to building the
> root image will work across various Linux distributions; perhaps it
> will be OK, since all of the libraries that dracut will siphon in will
> have to be in place to meet the build requirements for QEMU to begin
> with.
>
> However, I have zero knowledge about ARM-based Xen or where
> NetBSD is used for dom0, and how they might affect the decisionmaking.
> I also do not know what lessons have been learned from building other
> stubdoms, rumpkernel, or Mirage that might inform these decisions.
> In other words, what do you see as a sensible build scheme? The
> approach taken in the patches strikes me as too hacky for release
> quality, but maybe it is OK...
It looks OK to me but I am not an expert in this kind of things. I'll
let Ian Campbell and Ian Jackson (CC'ed) comment on it.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 1/7] linux-stubdomain: Compile QEMU
2015-02-06 15:46 ` Stefano Stabellini
@ 2015-02-06 17:25 ` Eric Shelton
2015-02-06 17:27 ` Stefano Stabellini
2015-02-06 18:57 ` Wei Liu
0 siblings, 2 replies; 43+ messages in thread
From: Eric Shelton @ 2015-02-06 17:25 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Anthony PERARD, xen-devel, Ian Campbell
On Fri, Feb 6, 2015 at 10:46 AM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 3 Feb 2015, Eric Shelton wrote:
> Before having patches, I would like to try to get them upstream in QEMU.
> If we really cannot do that, then I would still prefer to commit any
> required workarounds to the qemu-xen rather than having them here as
> patches.
Absolutely; the intent is to upstream the changes to QEMU, and
eliminate the patching to QEMU being done in the patchset I sent out.
I just need to sort out all of the QEMU changes first...
>> diff --git a/stubdom-linux/qemu-xen-common.patch b/stubdom-linux/qemu-xen-common.patch
>> new file mode 100644
>> index 0000000..b473e36
>> --- /dev/null
>> +++ b/stubdom-linux/qemu-xen-common.patch
>> @@ -0,0 +1,12 @@
>> +--- a/xen-common.c 2015-01-25 20:42:36.329999998 -0500
>> ++++ b/xen-common.c 2015-01-25 20:43:20.346666663 -0500
>> +@@ -92,7 +92,8 @@
>> + exit(1);
>> + }
>> +
>> +- snprintf(path, sizeof (path), "device-model/%u/state", xen_domid);
>> ++ snprintf(path, sizeof (path),
>> ++ "/local/domain/0/device-model/%u/state", xen_domid);
>
> Even if this counts as a workaround, I think it could go upstream in
> QEMU.
Agreed, although I will likely follow Wei's suggestion to use a
/local/domain/{stubdom-id}/... path, instead of under dom0's tree in
xenstore.
>> diff --git a/stubdom-linux/qemu-xen-h.patch b/stubdom-linux/qemu-xen-h.patch
>> new file mode 100644
>> index 0000000..262b1d1
>> --- /dev/null
>> +++ b/stubdom-linux/qemu-xen-h.patch
>> @@ -0,0 +1,18 @@
>> +--- a/include/hw/xen/xen.h 2015-01-21 23:54:36.856666662 -0500
>> ++++ b/include/hw/xen/xen.h 2015-01-21 23:55:39.356666667 -0500
>> +@@ -28,6 +28,15 @@
>> + return xen_allowed;
>> + }
>> +
>> ++static inline int xen_stubdom_enable(void)
>> ++{
>> ++#ifdef CONFIG_STUBDOM
>> ++ return 1;
>> ++#else
>> ++ return 0;
>> ++#endif
>> ++}
>
> As the STUBDOM related changes are small, I think we could avoid to
> introduce this config option altogether.
>
> Maybe we could figure out that we are running as stubdom with a runtime
> option, like a command line argument, something on xenstore or even our
> own domain id.
I will have to check - there may have been other preexisting uses of
CONFIG_STUBDOM is QEMU-upstream that might further encourage its use.
I'm also not sure if we get much benefit out of doing runtime checks
instead of ifdef's, since I think we'll end up having to do a separate
build of QEMU for stubdom anyways.
- Eric
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 1/7] linux-stubdomain: Compile QEMU
2015-02-06 17:25 ` Eric Shelton
@ 2015-02-06 17:27 ` Stefano Stabellini
2015-02-06 18:57 ` Wei Liu
1 sibling, 0 replies; 43+ messages in thread
From: Stefano Stabellini @ 2015-02-06 17:27 UTC (permalink / raw)
To: Eric Shelton; +Cc: Anthony PERARD, xen-devel, Ian Campbell, Stefano Stabellini
On Fri, 6 Feb 2015, Eric Shelton wrote:
> On Fri, Feb 6, 2015 at 10:46 AM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Tue, 3 Feb 2015, Eric Shelton wrote:
>
> > Before having patches, I would like to try to get them upstream in QEMU.
> > If we really cannot do that, then I would still prefer to commit any
> > required workarounds to the qemu-xen rather than having them here as
> > patches.
>
> Absolutely; the intent is to upstream the changes to QEMU, and
> eliminate the patching to QEMU being done in the patchset I sent out.
> I just need to sort out all of the QEMU changes first...
>
> >> diff --git a/stubdom-linux/qemu-xen-common.patch b/stubdom-linux/qemu-xen-common.patch
> >> new file mode 100644
> >> index 0000000..b473e36
> >> --- /dev/null
> >> +++ b/stubdom-linux/qemu-xen-common.patch
> >> @@ -0,0 +1,12 @@
> >> +--- a/xen-common.c 2015-01-25 20:42:36.329999998 -0500
> >> ++++ b/xen-common.c 2015-01-25 20:43:20.346666663 -0500
> >> +@@ -92,7 +92,8 @@
> >> + exit(1);
> >> + }
> >> +
> >> +- snprintf(path, sizeof (path), "device-model/%u/state", xen_domid);
> >> ++ snprintf(path, sizeof (path),
> >> ++ "/local/domain/0/device-model/%u/state", xen_domid);
> >
> > Even if this counts as a workaround, I think it could go upstream in
> > QEMU.
>
> Agreed, although I will likely follow Wei's suggestion to use a
> /local/domain/{stubdom-id}/... path, instead of under dom0's tree in
> xenstore.
>
> >> diff --git a/stubdom-linux/qemu-xen-h.patch b/stubdom-linux/qemu-xen-h.patch
> >> new file mode 100644
> >> index 0000000..262b1d1
> >> --- /dev/null
> >> +++ b/stubdom-linux/qemu-xen-h.patch
> >> @@ -0,0 +1,18 @@
> >> +--- a/include/hw/xen/xen.h 2015-01-21 23:54:36.856666662 -0500
> >> ++++ b/include/hw/xen/xen.h 2015-01-21 23:55:39.356666667 -0500
> >> +@@ -28,6 +28,15 @@
> >> + return xen_allowed;
> >> + }
> >> +
> >> ++static inline int xen_stubdom_enable(void)
> >> ++{
> >> ++#ifdef CONFIG_STUBDOM
> >> ++ return 1;
> >> ++#else
> >> ++ return 0;
> >> ++#endif
> >> ++}
> >
> > As the STUBDOM related changes are small, I think we could avoid to
> > introduce this config option altogether.
> >
> > Maybe we could figure out that we are running as stubdom with a runtime
> > option, like a command line argument, something on xenstore or even our
> > own domain id.
>
> I will have to check - there may have been other preexisting uses of
> CONFIG_STUBDOM is QEMU-upstream that might further encourage its use.
> I'm also not sure if we get much benefit out of doing runtime checks
> instead of ifdef's, since I think we'll end up having to do a separate
> build of QEMU for stubdom anyways.
The benefit would be avoiding the introduction of CONFIG_STUBDOM as the
QEMU community might not be too keen on it. But it is worth a try.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 2/7] linux-stubdomain: Compile Linux
2015-02-06 15:51 ` Stefano Stabellini
@ 2015-02-06 17:42 ` Eric Shelton
2015-02-06 17:45 ` Stefano Stabellini
0 siblings, 1 reply; 43+ messages in thread
From: Eric Shelton @ 2015-02-06 17:42 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Anthony PERARD, xen-devel, Ian Campbell
On Fri, Feb 6, 2015 at 10:51 AM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 3 Feb 2015, Eric Shelton wrote:
>> This patch adds rules to the Makefile to retrieve Linux and build a
>> minimal kernel for the stubdomain. Using Linux kernel 3.17.8.
>>
>> In order to work as a stubdomain, two patches are applied to the Linux
>> kernel source.
>
> Similarly to QEMU, we should get the changes upstream in Linux.
> Failing that we could use a Linux tree on xenbits instead of a stable
> kernel release and apply and needed workarounds there.
Sounds good - if anything remains to be patched at all. As you
mentioned, one of the two patches is already upstreamed in 3.18, and
perhaps the other is no longer needed. I simply used the same kernel
version I was using for dom0 (earlier I ran into unknown problems with
3.18 for dom0). I will give a newer, and unpatched, kernel a try for
stubdom.
>> +diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
>> +index 682210d..032add4 100644
>> +--- a/drivers/tty/hvc/hvc_xen.c
>> ++++ b/drivers/tty/hvc/hvc_xen.c
>> +@@ -402,9 +402,6 @@ static int xencons_connect_backend(struct xenbus_device *dev,
>> + evtchn);
>> + if (ret)
>> + goto error_xenbus;
>> +- ret = xenbus_printf(xbt, dev->nodename, "type", "ioemu");
>> +- if (ret)
>> +- goto error_xenbus;
>> + ret = xenbus_transaction_end(xbt, 0);
>> + if (ret) {
>> + if (ret == -EAGAIN)
>
> I think that this is already upstream
Indeed, you are correct, but not until 3.18. I will have to move to a
newer kernel.
>> +diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
>> +index 69f5857..999fc82 100644
>> +--- a/arch/x86/xen/mmu.c
>> ++++ b/arch/x86/xen/mmu.c
>> +@@ -2606,7 +2606,20 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
>> + unsigned long addr, void *data)
>> + {
>> + struct remap_data *rmd = data;
>> +- pte_t pte = pte_mkspecial(mfn_pte(rmd->mfn++, rmd->prot));
>> ++
>> ++ /* Use the native_make_pte function because we are sure we don't
>> ++ * have to do any pfn->mfn translations but at the same time we
>> ++ * could in a stubdom so xen_initial_domain() would return false. */
>> ++ pte_t pte = pte_mkspecial(native_make_pte(((phys_addr_t)(rmd->mfn++) << PAGE_SHIFT)
>> ++ | massage_pgprot(rmd->prot)));
>> ++ pteval_t val = pte_val_ma(pte);
>> ++
>> ++#if 0
>> ++ if (pat_enabled && !WARN_ON(val & _PAGE_PAT)) {
>> ++ if ((val & (_PAGE_PCD | _PAGE_PWT)) == _PAGE_PWT)
>> ++ val = (val & ~(_PAGE_PCD | _PAGE_PWT)) | _PAGE_PAT;
>> ++ }
>> ++#endif
>
> I don't think you need this change anymore with a more recent kernel.
> In any case, a proper fix for this issue would certainly be welcome
> upstream in Linux.
I will see how it goes.
>> +LINUX_URL=ftp://ftp.kernel.org/pub/linux/kernel/v3.x/$(LINUX_V).tar.xz
>> +
>> +all: $(VMLINUZ)
>
> I think it is best if we git clone it.
Is that still true if unpatched 3.18.6 works? I don't know if there
is a desire to reduce load on kernel.org, for example.
>> +++ b/stubdom-linux/stubdom-linux-config-64b
>> @@ -0,0 +1,1510 @@
>> +#
>> +# Automatically generated file; DO NOT EDIT.
>> +# Linux/x86 3.17.8 Kernel Configuration
>
> Where does it come from?
> Is it the defconfig?
I took the 3.10 .config used in Anthony's original patches and ran a
'make oldconfig', and maybe tweaked one or two configs along the way.
I imagine the config can be pared down further by more experienced
eyes.
- Eric
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 3/7] linux-stubdomain: Build a disk image
2015-02-06 15:57 ` Stefano Stabellini
@ 2015-02-06 17:45 ` Eric Shelton
0 siblings, 0 replies; 43+ messages in thread
From: Eric Shelton @ 2015-02-06 17:45 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Anthony PERARD, xen-devel, Ian Campbell
On Fri, Feb 6, 2015 at 10:57 AM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 3 Feb 2015, Eric Shelton wrote:
>> +DRACUT_URL="http://www.kernel.org/pub/linux/utils/boot/dracut"
>> +DRACUT_V=dracut-033
>> +
>> +GENEXT2FS_V = 1.4.1
>> +GENEXT2FS_URL="http://sourceforge.net/projects/genext2fs/files/genext2fs/$(GENEXT2FS_V)/genext2fs-$(GENEXT2FS_V).tar.gz/download"
>
> I don't think that we need to download install these tools. They are
> available on all major distros.
> I think we could add them as dependency to the xen-unstable configure
> script.
OK. I need to start moving this over to something more integrated
with the entire Xen configure script process anyway.
- Eric
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 2/7] linux-stubdomain: Compile Linux
2015-02-06 17:42 ` Eric Shelton
@ 2015-02-06 17:45 ` Stefano Stabellini
2015-02-09 9:09 ` Ian Campbell
2015-05-14 9:08 ` George Dunlap
0 siblings, 2 replies; 43+ messages in thread
From: Stefano Stabellini @ 2015-02-06 17:45 UTC (permalink / raw)
To: Eric Shelton; +Cc: Anthony PERARD, xen-devel, Ian Campbell, Stefano Stabellini
On Fri, 6 Feb 2015, Eric Shelton wrote:
> On Fri, Feb 6, 2015 at 10:51 AM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Tue, 3 Feb 2015, Eric Shelton wrote:
> >> This patch adds rules to the Makefile to retrieve Linux and build a
> >> minimal kernel for the stubdomain. Using Linux kernel 3.17.8.
> >>
> >> In order to work as a stubdomain, two patches are applied to the Linux
> >> kernel source.
> >
> > Similarly to QEMU, we should get the changes upstream in Linux.
> > Failing that we could use a Linux tree on xenbits instead of a stable
> > kernel release and apply and needed workarounds there.
>
> Sounds good - if anything remains to be patched at all. As you
> mentioned, one of the two patches is already upstreamed in 3.18, and
> perhaps the other is no longer needed. I simply used the same kernel
> version I was using for dom0 (earlier I ran into unknown problems with
> 3.18 for dom0). I will give a newer, and unpatched, kernel a try for
> stubdom.
>
> >> +diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> >> +index 682210d..032add4 100644
> >> +--- a/drivers/tty/hvc/hvc_xen.c
> >> ++++ b/drivers/tty/hvc/hvc_xen.c
> >> +@@ -402,9 +402,6 @@ static int xencons_connect_backend(struct xenbus_device *dev,
> >> + evtchn);
> >> + if (ret)
> >> + goto error_xenbus;
> >> +- ret = xenbus_printf(xbt, dev->nodename, "type", "ioemu");
> >> +- if (ret)
> >> +- goto error_xenbus;
> >> + ret = xenbus_transaction_end(xbt, 0);
> >> + if (ret) {
> >> + if (ret == -EAGAIN)
> >
> > I think that this is already upstream
>
> Indeed, you are correct, but not until 3.18. I will have to move to a
> newer kernel.
>
> >> +diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> >> +index 69f5857..999fc82 100644
> >> +--- a/arch/x86/xen/mmu.c
> >> ++++ b/arch/x86/xen/mmu.c
> >> +@@ -2606,7 +2606,20 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
> >> + unsigned long addr, void *data)
> >> + {
> >> + struct remap_data *rmd = data;
> >> +- pte_t pte = pte_mkspecial(mfn_pte(rmd->mfn++, rmd->prot));
> >> ++
> >> ++ /* Use the native_make_pte function because we are sure we don't
> >> ++ * have to do any pfn->mfn translations but at the same time we
> >> ++ * could in a stubdom so xen_initial_domain() would return false. */
> >> ++ pte_t pte = pte_mkspecial(native_make_pte(((phys_addr_t)(rmd->mfn++) << PAGE_SHIFT)
> >> ++ | massage_pgprot(rmd->prot)));
> >> ++ pteval_t val = pte_val_ma(pte);
> >> ++
> >> ++#if 0
> >> ++ if (pat_enabled && !WARN_ON(val & _PAGE_PAT)) {
> >> ++ if ((val & (_PAGE_PCD | _PAGE_PWT)) == _PAGE_PWT)
> >> ++ val = (val & ~(_PAGE_PCD | _PAGE_PWT)) | _PAGE_PAT;
> >> ++ }
> >> ++#endif
> >
> > I don't think you need this change anymore with a more recent kernel.
> > In any case, a proper fix for this issue would certainly be welcome
> > upstream in Linux.
>
> I will see how it goes.
>
> >> +LINUX_URL=ftp://ftp.kernel.org/pub/linux/kernel/v3.x/$(LINUX_V).tar.xz
> >> +
> >> +all: $(VMLINUZ)
> >
> > I think it is best if we git clone it.
>
> Is that still true if unpatched 3.18.6 works? I don't know if there
> is a desire to reduce load on kernel.org, for example.
That's a good point. I think git clone would be more inline with any
other external project that we use. However I'll let the other
maintainers decide on this.
> >> +++ b/stubdom-linux/stubdom-linux-config-64b
> >> @@ -0,0 +1,1510 @@
> >> +#
> >> +# Automatically generated file; DO NOT EDIT.
> >> +# Linux/x86 3.17.8 Kernel Configuration
> >
> > Where does it come from?
> > Is it the defconfig?
>
> I took the 3.10 .config used in Anthony's original patches and ran a
> 'make oldconfig', and maybe tweaked one or two configs along the way.
> I imagine the config can be pared down further by more experienced
> eyes.
>
> - Eric
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 4/7] libxl: Add "stubdomain_version" to domain_build_info.
2015-02-06 16:06 ` Stefano Stabellini
@ 2015-02-06 17:50 ` Eric Shelton
2015-02-06 17:54 ` Stefano Stabellini
0 siblings, 1 reply; 43+ messages in thread
From: Eric Shelton @ 2015-02-06 17:50 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Anthony PERARD, xen-devel, Ian Campbell
On Fri, Feb 6, 2015 at 11:06 AM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 3 Feb 2015, Eric Shelton wrote:
>> This enum gives the ability to select between a MiniOS-based QEMU
>> traditional stub domain and a Linux-based QEMU upstream stub domain. To
>> use the Linux-based stubdomain, the following two lines should be
>> included in the appropriate xl.cfg file:
>>
>> device_model_version="qemu-xen"
>> device_model_stubdomain_override=1
>>
>> To use the MiniOS-based stubdomain, the following is used instead:
>>
>> device_model_version="qemu-xen-traditional"
>> device_model_stubdomain_override=1
...
>> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>> index 02be466..8d0ac3b 100644
>> --- a/tools/libxl/libxl_types.idl
>> +++ b/tools/libxl/libxl_types.idl
>> @@ -83,6 +83,12 @@ libxl_device_model_version = Enumeration("device_model_version", [
>> (2, "QEMU_XEN"), # Upstream based qemu-xen device model
>> ])
>>
>> +# Give the kernel running in the stub-domain
>> +libxl_stubdomain_version = Enumeration("stubdomain_version", [
>
> This should just be called stubdomain_version.
I'm sorry - I don't quite catch what you are suggesting. Are you
saying that the VM config file should have a line like this?
stubdomain_version="linux"
- Eric
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 4/7] libxl: Add "stubdomain_version" to domain_build_info.
2015-02-06 17:50 ` Eric Shelton
@ 2015-02-06 17:54 ` Stefano Stabellini
0 siblings, 0 replies; 43+ messages in thread
From: Stefano Stabellini @ 2015-02-06 17:54 UTC (permalink / raw)
To: Eric Shelton; +Cc: Anthony PERARD, xen-devel, Ian Campbell, Stefano Stabellini
On Fri, 6 Feb 2015, Eric Shelton wrote:
> On Fri, Feb 6, 2015 at 11:06 AM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Tue, 3 Feb 2015, Eric Shelton wrote:
> >> This enum gives the ability to select between a MiniOS-based QEMU
> >> traditional stub domain and a Linux-based QEMU upstream stub domain. To
> >> use the Linux-based stubdomain, the following two lines should be
> >> included in the appropriate xl.cfg file:
> >>
> >> device_model_version="qemu-xen"
> >> device_model_stubdomain_override=1
> >>
> >> To use the MiniOS-based stubdomain, the following is used instead:
> >>
> >> device_model_version="qemu-xen-traditional"
> >> device_model_stubdomain_override=1
>
> ...
>
> >> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> >> index 02be466..8d0ac3b 100644
> >> --- a/tools/libxl/libxl_types.idl
> >> +++ b/tools/libxl/libxl_types.idl
> >> @@ -83,6 +83,12 @@ libxl_device_model_version = Enumeration("device_model_version", [
> >> (2, "QEMU_XEN"), # Upstream based qemu-xen device model
> >> ])
> >>
> >> +# Give the kernel running in the stub-domain
> >> +libxl_stubdomain_version = Enumeration("stubdomain_version", [
> >
> > This should just be called stubdomain_version.
>
> I'm sorry - I don't quite catch what you are suggesting. Are you
> saying that the VM config file should have a line like this?
>
> stubdomain_version="linux"
Sorry I misread your patch. Ignore my previous comment.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 1/7] linux-stubdomain: Compile QEMU
2015-02-06 17:25 ` Eric Shelton
2015-02-06 17:27 ` Stefano Stabellini
@ 2015-02-06 18:57 ` Wei Liu
1 sibling, 0 replies; 43+ messages in thread
From: Wei Liu @ 2015-02-06 18:57 UTC (permalink / raw)
To: Eric Shelton
Cc: Anthony PERARD, xen-devel, wei.liu2, Ian Campbell, Stefano Stabellini
On Fri, Feb 06, 2015 at 12:25:33PM -0500, Eric Shelton wrote:
> On Fri, Feb 6, 2015 at 10:46 AM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Tue, 3 Feb 2015, Eric Shelton wrote:
>
> > Before having patches, I would like to try to get them upstream in QEMU.
> > If we really cannot do that, then I would still prefer to commit any
> > required workarounds to the qemu-xen rather than having them here as
> > patches.
>
> Absolutely; the intent is to upstream the changes to QEMU, and
> eliminate the patching to QEMU being done in the patchset I sent out.
> I just need to sort out all of the QEMU changes first...
>
> >> diff --git a/stubdom-linux/qemu-xen-common.patch b/stubdom-linux/qemu-xen-common.patch
> >> new file mode 100644
> >> index 0000000..b473e36
> >> --- /dev/null
> >> +++ b/stubdom-linux/qemu-xen-common.patch
> >> @@ -0,0 +1,12 @@
> >> +--- a/xen-common.c 2015-01-25 20:42:36.329999998 -0500
> >> ++++ b/xen-common.c 2015-01-25 20:43:20.346666663 -0500
> >> +@@ -92,7 +92,8 @@
> >> + exit(1);
> >> + }
> >> +
> >> +- snprintf(path, sizeof (path), "device-model/%u/state", xen_domid);
> >> ++ snprintf(path, sizeof (path),
> >> ++ "/local/domain/0/device-model/%u/state", xen_domid);
> >
> > Even if this counts as a workaround, I think it could go upstream in
> > QEMU.
>
> Agreed, although I will likely follow Wei's suggestion to use a
> /local/domain/{stubdom-id}/... path, instead of under dom0's tree in
> xenstore.
>
I guess if you don't use absolute path it should just writes to
/local/domain/$stubdom_id. (This has a restriction that it doesn't work
with xenstore connection opened with socket.)
Since you're at it, could you try to
1) retain the relative path used here, so that it writes to ~ (from
stubdom's PoV it is /local/domain/$stubdom_id, that's the theory)
2) modify patch 7/7 to use the /local/domain/$stubdom_id path.
My hunch is that it is not too complicated to retrieve stubdom_id in
libxl (it should be available somewhere).
A side note is that you may need to grant write permission the stubdom to
write to its own path. Search for XS_PERM_ in libxl_dm.c you will see
some place using "/local/domain/0".
That's what I would do to tackle this whole problem. I haven't tried it
personally though (got distracted half way).
Wei.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 7/7] libxl: Wait for QEMU startup in stubdomain
2015-02-06 17:23 ` Stefano Stabellini
@ 2015-02-09 9:07 ` Ian Campbell
2015-02-09 9:14 ` Stefano Stabellini
2015-02-09 12:08 ` Anthony PERARD
0 siblings, 2 replies; 43+ messages in thread
From: Ian Campbell @ 2015-02-09 9:07 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Anthony PERARD, Ian Jackson, xen-devel, Wei Liu, Eric Shelton
On Fri, 2015-02-06 at 17:23 +0000, Stefano Stabellini wrote:
> >
> > One of the main issues outstanding from when Anthony originally posted
> > his patches is how we want to go about building this? I honestly do
> > not know how well the current dracut-based approach to building the
> > root image will work across various Linux distributions; perhaps it
> > will be OK, since all of the libraries that dracut will siphon in will
> > have to be in place to meet the build requirements for QEMU to begin
> > with.
> >
> > However, I have zero knowledge about ARM-based Xen or where
> > NetBSD is used for dom0, and how they might affect the decisionmaking.
> > I also do not know what lessons have been learned from building other
> > stubdoms, rumpkernel, or Mirage that might inform these decisions.
> > In other words, what do you see as a sensible build scheme? The
> > approach taken in the patches strikes me as too hacky for release
> > quality, but maybe it is OK...
>
> It looks OK to me but I am not an expert in this kind of things. I'll
> let Ian Campbell and Ian Jackson (CC'ed) comment on it.
I'm not at all keen on things like the use of dracut (or mkinitramfs or
similar) in Xen's build since they are inherently/inevitably specific to
the Linux distro they came from, so they often don't work (or aren't
even available on) other Linux distros and are an even bigger problem
for *BSD.
I've yet to see a solution for this which seemed satisfactory enough to
be included in Xen's system. Mirage, minios stubdoms, rumpkernels etc
all avoid this by not having a need for a rootfs.
But, it's not necessarily the case that the Xen project has to produce
the Linux stubdom binary as part of its build output. IMHO it would be
sufficient (for tech preview at least) if the tools would detect and use
a stubdom binary if it were present at some well defined path so long as
the for the runes to build the image were documented somewhere (e.g.in
the wiki, in docs/misc, in some script, etc). Then the problems of them
being distro/kernel specific are somewhat mitigated (e.g. a Fedora fan
can write dracut instructions, a Debian fan can write mkinitramfs ones
and a BSD fan can make it work with a BSD kernel etc etc) and we avoid
having to have rootfs construction code in Xen's build.
Ian.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 2/7] linux-stubdomain: Compile Linux
2015-02-06 17:45 ` Stefano Stabellini
@ 2015-02-09 9:09 ` Ian Campbell
2015-05-14 9:08 ` George Dunlap
1 sibling, 0 replies; 43+ messages in thread
From: Ian Campbell @ 2015-02-09 9:09 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Anthony PERARD, xen-devel, Eric Shelton
On Fri, 2015-02-06 at 17:45 +0000, Stefano Stabellini wrote:
> That's a good point. I think git clone would be more inline with any
> other external project that we use. However I'll let the other
> maintainers decide on this.
If anything it should be a clone of a push-gated Linux git tree on
xenbits.xen.org.
Ian.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 4/7] libxl: Add "stubdomain_version" to domain_build_info.
2015-02-04 4:06 ` [RFC 4/7] libxl: Add "stubdomain_version" to domain_build_info Eric Shelton
2015-02-06 16:06 ` Stefano Stabellini
@ 2015-02-09 9:11 ` Ian Campbell
2015-02-09 14:11 ` Eric Shelton
1 sibling, 1 reply; 43+ messages in thread
From: Ian Campbell @ 2015-02-09 9:11 UTC (permalink / raw)
To: Eric Shelton; +Cc: anthony.perard, xen-devel, stefano.stabellini
On Tue, 2015-02-03 at 23:06 -0500, Eric Shelton wrote:
> This enum gives the ability to select between a MiniOS-based QEMU
> traditional stub domain and a Linux-based QEMU upstream stub domain. To
> use the Linux-based stubdomain, the following two lines should be
> included in the appropriate xl.cfg file:
>
> device_model_version="qemu-xen"
> device_model_stubdomain_override=1
>
> To use the MiniOS-based stubdomain, the following is used instead:
>
> device_model_version="qemu-xen-traditional"
> device_model_stubdomain_override=1
This doesn't seem to use this new stubdom_version option and I'm not
really sure what it is for.
Perhaps you meant this new thing to be a libxl internal Enum, rather
than exposed to the application which is using libxl? I'm not sure wy
the user would need to be given the choice -- it should be inherent in
the device-model version and stubdom boolean selection.
Ian.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 7/7] libxl: Wait for QEMU startup in stubdomain
2015-02-09 9:07 ` Ian Campbell
@ 2015-02-09 9:14 ` Stefano Stabellini
2015-02-09 12:08 ` Anthony PERARD
1 sibling, 0 replies; 43+ messages in thread
From: Stefano Stabellini @ 2015-02-09 9:14 UTC (permalink / raw)
To: Ian Campbell
Cc: xen-devel, Wei Liu, Stefano Stabellini, Ian Jackson,
Anthony PERARD, Eric Shelton
On Mon, 9 Feb 2015, Ian Campbell wrote:
> On Fri, 2015-02-06 at 17:23 +0000, Stefano Stabellini wrote:
> > >
> > > One of the main issues outstanding from when Anthony originally posted
> > > his patches is how we want to go about building this? I honestly do
> > > not know how well the current dracut-based approach to building the
> > > root image will work across various Linux distributions; perhaps it
> > > will be OK, since all of the libraries that dracut will siphon in will
> > > have to be in place to meet the build requirements for QEMU to begin
> > > with.
> > >
> > > However, I have zero knowledge about ARM-based Xen or where
> > > NetBSD is used for dom0, and how they might affect the decisionmaking.
> > > I also do not know what lessons have been learned from building other
> > > stubdoms, rumpkernel, or Mirage that might inform these decisions.
> > > In other words, what do you see as a sensible build scheme? The
> > > approach taken in the patches strikes me as too hacky for release
> > > quality, but maybe it is OK...
> >
> > It looks OK to me but I am not an expert in this kind of things. I'll
> > let Ian Campbell and Ian Jackson (CC'ed) comment on it.
>
> I'm not at all keen on things like the use of dracut (or mkinitramfs or
> similar) in Xen's build since they are inherently/inevitably specific to
> the Linux distro they came from, so they often don't work (or aren't
> even available on) other Linux distros and are an even bigger problem
> for *BSD.
>
> I've yet to see a solution for this which seemed satisfactory enough to
> be included in Xen's system. Mirage, minios stubdoms, rumpkernels etc
> all avoid this by not having a need for a rootfs.
>
> But, it's not necessarily the case that the Xen project has to produce
> the Linux stubdom binary as part of its build output. IMHO it would be
> sufficient (for tech preview at least) if the tools would detect and use
> a stubdom binary if it were present at some well defined path so long as
> the for the runes to build the image were documented somewhere (e.g.in
> the wiki, in docs/misc, in some script, etc). Then the problems of them
> being distro/kernel specific are somewhat mitigated (e.g. a Fedora fan
> can write dracut instructions, a Debian fan can write mkinitramfs ones
> and a BSD fan can make it work with a BSD kernel etc etc) and we avoid
> having to have rootfs construction code in Xen's build.
I don't have an opinion on whether the stubdom build system should be
in tree or out of tree, as long it can be used in OSSTest.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 7/7] libxl: Wait for QEMU startup in stubdomain
2015-02-09 9:07 ` Ian Campbell
2015-02-09 9:14 ` Stefano Stabellini
@ 2015-02-09 12:08 ` Anthony PERARD
2015-02-09 13:57 ` Eric Shelton
1 sibling, 1 reply; 43+ messages in thread
From: Anthony PERARD @ 2015-02-09 12:08 UTC (permalink / raw)
To: Ian Campbell
Cc: Ian Jackson, Eric Shelton, Wei Liu, xen-devel, Stefano Stabellini
On Mon, Feb 09, 2015 at 09:07:13AM +0000, Ian Campbell wrote:
> On Fri, 2015-02-06 at 17:23 +0000, Stefano Stabellini wrote:
> > >
> > > One of the main issues outstanding from when Anthony originally posted
> > > his patches is how we want to go about building this? I honestly do
> > > not know how well the current dracut-based approach to building the
> > > root image will work across various Linux distributions; perhaps it
> > > will be OK, since all of the libraries that dracut will siphon in will
> > > have to be in place to meet the build requirements for QEMU to begin
> > > with.
> > >
> > > However, I have zero knowledge about ARM-based Xen or where
> > > NetBSD is used for dom0, and how they might affect the decisionmaking.
> > > I also do not know what lessons have been learned from building other
> > > stubdoms, rumpkernel, or Mirage that might inform these decisions.
> > > In other words, what do you see as a sensible build scheme? The
> > > approach taken in the patches strikes me as too hacky for release
> > > quality, but maybe it is OK...
> >
> > It looks OK to me but I am not an expert in this kind of things. I'll
> > let Ian Campbell and Ian Jackson (CC'ed) comment on it.
>
> I'm not at all keen on things like the use of dracut (or mkinitramfs or
> similar) in Xen's build since they are inherently/inevitably specific to
> the Linux distro they came from, so they often don't work (or aren't
> even available on) other Linux distros and are an even bigger problem
> for *BSD.
I'd like to precise that the use of dracut here is only to copy a binary
and it's dependencies (shared libraries), the binary used is called
dracut-installer. I guest that the same can be achieved by the copy_exec()
function from mkinitramfs (found in
/usr/share/initramfs-tools/hook-functions on a debian system).
The rest is done by a script, which choose which binary and file to include
in the rootfs, where to put them and how to generate the image.
--
Anthony PERARD
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 7/7] libxl: Wait for QEMU startup in stubdomain
2015-02-09 12:08 ` Anthony PERARD
@ 2015-02-09 13:57 ` Eric Shelton
0 siblings, 0 replies; 43+ messages in thread
From: Eric Shelton @ 2015-02-09 13:57 UTC (permalink / raw)
To: Anthony PERARD
Cc: Ian Jackson, xen-devel, Wei Liu, Ian Campbell, Stefano Stabellini
On Mon, Feb 9, 2015 at 7:08 AM, Anthony PERARD
<anthony.perard@citrix.com> wrote:
> On Mon, Feb 09, 2015 at 09:07:13AM +0000, Ian Campbell wrote:
>> On Fri, 2015-02-06 at 17:23 +0000, Stefano Stabellini wrote:
>> > >
>> > > One of the main issues outstanding from when Anthony originally posted
>> > > his patches is how we want to go about building this? I honestly do
>> > > not know how well the current dracut-based approach to building the
>> > > root image will work across various Linux distributions; perhaps it
>> > > will be OK, since all of the libraries that dracut will siphon in will
>> > > have to be in place to meet the build requirements for QEMU to begin
>> > > with.
>> > >
>> > > However, I have zero knowledge about ARM-based Xen or where
>> > > NetBSD is used for dom0, and how they might affect the decisionmaking.
>> > > I also do not know what lessons have been learned from building other
>> > > stubdoms, rumpkernel, or Mirage that might inform these decisions.
>> > > In other words, what do you see as a sensible build scheme? The
>> > > approach taken in the patches strikes me as too hacky for release
>> > > quality, but maybe it is OK...
>> >
>> > It looks OK to me but I am not an expert in this kind of things. I'll
>> > let Ian Campbell and Ian Jackson (CC'ed) comment on it.
>>
>> I'm not at all keen on things like the use of dracut (or mkinitramfs or
>> similar) in Xen's build since they are inherently/inevitably specific to
>> the Linux distro they came from, so they often don't work (or aren't
>> even available on) other Linux distros and are an even bigger problem
>> for *BSD.
OK. Maybe pulling *BSD into this is too much at this time, because
the process of building Linux, QEMU (for Linux), and all of the
dependant libraries blows up into a much larger issue once we are no
longer on Linux. Someone once suggested using Yocto; I don't know if
this works under *BSD. Instead, we might have to use a Linux-based VM
to build a Linux-based stubdom - but then, what do we use for the
Linux-based VM?
I propose we target the following for tech preview: if you are
building Xen on Linux x86_64, stubdom-linux (i.e., its Linux kernel
and the rootfs containing QEMU and the libraries it requires) _can_ be
automatically built as part of the Xen build (but perhaps not by
default). Under these conditions, we should have everything we need
at hand - if you are on Linux and can compile QEMU-upstream for dom0,
I see no reason why you cannot also assemble a Linux-based
QEMU-upstream stubdom.
> I'd like to precise that the use of dracut here is only to copy a binary
> and it's dependencies (shared libraries), the binary used is called
> dracut-installer. I guest that the same can be achieved by the copy_exec()
> function from mkinitramfs (found in
> /usr/share/initramfs-tools/hook-functions on a debian system).
>
> The rest is done by a script, which choose which binary and file to include
> in the rootfs, where to put them and how to generate the image.
To make this discussion a little more concrete, I have put a listing
of the contents of the rootfs that is currently being built at the end
of this email. Maybe it will help to see there really is not all that
much in there. For the most part, the difficult part of putting
together the rootfs, in terms of an automatic build, is determining
which libraries go into /lib64.
Anthony's solution to this was to use dracut, and it does this very
well. To not use dracut (or possibly some equivalent function of
mkinitramfs) would just mean we would end up replicating its
functionality (or at least the subset of its functionality we rely
upon).
I see a couple of relatively simple paths to pursue:
(1) Do what is being done now: download dracut (from the Xen git repo
or elsewhere), compile it, and use it to copy over the libraries we
need for QEMU. Is there some reason that dracut does not work across
Linux distros? We could skip downloading and compiling on a system
that already has dracut installed.
(2) Have a configure script dependency requiring _either_ dracut or
mkinitramfs. We use whichever one is available.
>> I've yet to see a solution for this which seemed satisfactory enough to
>> be included in Xen's system. Mirage, minios stubdoms, rumpkernels etc
>> all avoid this by not having a need for a rootfs.
OK, so these may not provide us with helpful prototypes. If the
stubdom is based on Linux, we _have_ to have a rootfs, whether served
up via blkback (current solution) or rolled into an initramfs and
tucked into the kernel (which was tried in the past, but increased the
memory overhead for the stubdom). So, how do we build the rootfs?
>> But, it's not necessarily the case that the Xen project has to produce
>> the Linux stubdom binary as part of its build output. IMHO it would be
>> sufficient (for tech preview at least) if the tools would detect and use
>> a stubdom binary if it were present at some well defined path so long as
>> the for the runes to build the image were documented somewhere (e.g.in
>> the wiki, in docs/misc, in some script, etc). Then the problems of them
>> being distro/kernel specific are somewhat mitigated (e.g. a Fedora fan
>> can write dracut instructions, a Debian fan can write mkinitramfs ones
>> and a BSD fan can make it work with a BSD kernel etc etc) and we avoid
>> having to have rootfs construction code in Xen's build.
This is just pushing the problem down the line. I don't see why we
cannot come up with something that is portable across Linux distros.
Right now, at least on Linux, building the Linux-based stubdom and
rootfs is pretty clean and quick - especially if you compare it to all
of the work required to roll up ioemu-stubdom.gz.
- Eric
Current contents of rootfs for Linux-based stubdom:
/bin
/bin/busybox
/bin/mount -> busybox
/bin/qemu
/bin/qemu-img
/bin/qemu-io
/bin/qemu-nbd
/bin/qemu-system-i386
/bin/virtfs-proxy-helper
/bin/xenstore-read
/dev
/etc
/etc/qemu
/etc/qemu-ifup
/etc/qemu/target-x86_64.conf
/init
/lib
/lib64
/lib64/ld-2.19.so
/lib64/ld-linux-x86-64.so.2 -> ld-2.19.so
/lib64/libaio.so.1 -> libaio.so.1.0.1
/lib64/libaio.so.1.0.1
/lib64/libbz2.so.1 -> libbz2.so.1.0.6
/lib64/libbz2.so.1.0.6
/lib64/libc-2.19.so
/lib64/libcrypto.so -> libcrypto.so.1.0.0
/lib64/libcrypto.so.1.0.0
/lib64/libc.so.6
/lib64/libcurl.so -> libcurl.so.4.3.0
/lib64/libcurl.so.4 -> libcurl.so.4.3.0
/lib64/libcurl.so.4.3.0
/lib64/libdl-2.19.so
/lib64/libdl.so.2 -> libdl-2.19.so
/lib64/libgcc_s.so -> libgcc_s.so.1
/lib64/libgcc_s.so.1
/lib64/libglib-2.0.so -> libglib-2.0.so.0.4000.0
/lib64/libglib-2.0.so.0 -> libglib-2.0.so.0.4000.0
/lib64/libglib-2.0.so.0.4000.0
/lib64/libgthread-2.0.so -> libgthread-2.0.so.0.4000.0
/lib64/libgthread-2.0.so.0 -> libgthread-2.0.so.0.4000.0
/lib64/libgthread-2.0.so.0.4000.0
/lib64/liblber-2.4.so.2 -> liblber-2.4.so.2.10.1
/lib64/liblber-2.4.so.2.10.1
/lib64/libldap-2.4.so.2 -> libldap-2.4.so.2.10.1
/lib64/libldap-2.4.so.2.10.1
/lib64/liblzma.so.5 -> liblzma.so.5.0.5
/lib64/liblzma.so.5.0.5
/lib64/liblzo2.so -> liblzo2.so.2.0.0
/lib64/liblzo2.so.2 -> liblzo2.so.2.0.0
/lib64/liblzo2.so.2.0.0
/lib64/libm-2.19.so
/lib64/libm.so.6 -> libm-2.19.so
/lib64/libpixman-1.so -> libpixman-1.so.0.32.4
/lib64/libpixman-1.so.0 -> libpixman-1.so.0.32.4
/lib64/libpixman-1.so.0.32.4
/lib64/libpthread-2.19.so
/lib64/libpthread.so.0 -> libpthread-2.19.so
/lib64/libresolv-2.19.so
/lib64/libresolv.so.2 -> libresolv-2.19.so
/lib64/librt-2.19.so
/lib64/librtmp.so -> librtmp.so.1
/lib64/librtmp.so.1
/lib64/librt.so.1 -> librt-2.19.so
/lib64/libssl.so -> libssl.so.1.0.0
/lib64/libssl.so.1.0.0
/lib64/libstdc++.so -> libstdc++.so.6.0.17
/lib64/libstdc++.so.6 -> libstdc++.so.6.0.17
/lib64/libstdc++.so.6.0.17
/lib64/libutil-2.19.so
/lib64/libutil.so.1 -> libutil-2.19.so
/lib64/libuuid.so.1 -> libuuid.so.1.3.0
/lib64/libuuid.so.1.3.0
/lib64/libxenctrl.so -> libxenctrl.so.4.5.0
/lib64/libxenctrl.so.4.5 -> libxenctrl.so.4.5.0
/lib64/libxenctrl.so.4.5.0
/lib64/libxenguest.so -> libxenguest.so.4.5.0
/lib64/libxenguest.so.4.5 -> libxenguest.so.4.5.0
/lib64/libxenguest.so.4.5.0
/lib64/libxenstore.so -> libxenstore.so.3.0.3
/lib64/libxenstore.so.3.0 -> libxenstore.so.3.0.3
/lib64/libxenstore.so.3.0.3
/lib64/libz.so.1 -> libz.so.1.2.8
/lib64/libz.so.1.2.8
/libexec
/libexec/qemu-bridge-helper
/proc
/proc/xen
/share
/share/qemu
/share/qemu/acpi-dsdt.aml
/share/qemu/bamboo.dtb
/share/qemu/bios-256k.bin
/share/qemu/bios.bin
/share/qemu/efi-e1000.rom
/share/qemu/efi-eepro100.rom
/share/qemu/efi-ne2k_pci.rom
/share/qemu/efi-pcnet.rom
/share/qemu/efi-rtl8139.rom
/share/qemu/efi-virtio.rom
/share/qemu/keymaps
/share/qemu/keymaps/ar
/share/qemu/keymaps/bepo
/share/qemu/keymaps/common
/share/qemu/keymaps/cz
/share/qemu/keymaps/da
/share/qemu/keymaps/de
/share/qemu/keymaps/de-ch
/share/qemu/keymaps/en-gb
/share/qemu/keymaps/en-us
/share/qemu/keymaps/es
/share/qemu/keymaps/et
/share/qemu/keymaps/fi
/share/qemu/keymaps/fo
/share/qemu/keymaps/fr
/share/qemu/keymaps/fr-be
/share/qemu/keymaps/fr-ca
/share/qemu/keymaps/fr-ch
/share/qemu/keymaps/hr
/share/qemu/keymaps/hu
/share/qemu/keymaps/is
/share/qemu/keymaps/it
/share/qemu/keymaps/ja
/share/qemu/keymaps/lt
/share/qemu/keymaps/lv
/share/qemu/keymaps/mk
/share/qemu/keymaps/modifiers
/share/qemu/keymaps/nl
/share/qemu/keymaps/nl-be
/share/qemu/keymaps/no
/share/qemu/keymaps/pl
/share/qemu/keymaps/pt
/share/qemu/keymaps/pt-br
/share/qemu/keymaps/ru
/share/qemu/keymaps/sl
/share/qemu/keymaps/sv
/share/qemu/keymaps/th
/share/qemu/keymaps/tr
/share/qemu/kvmvapic.bin
/share/qemu/linuxboot.bin
/share/qemu/multiboot.bin
/share/qemu/openbios-ppc
/share/qemu/openbios-sparc32
/share/qemu/openbios-sparc64
/share/qemu/palcode-clipper
/share/qemu/petalogix-ml605.dtb
/share/qemu/petalogix-s3adsp1800.dtb
/share/qemu/ppc_rom.bin
/share/qemu/pxe-e1000.rom
/share/qemu/pxe-eepro100.rom
/share/qemu/pxe-ne2k_pci.rom
/share/qemu/pxe-pcnet.rom
/share/qemu/pxe-rtl8139.rom
/share/qemu/pxe-virtio.rom
/share/qemu/q35-acpi-dsdt.aml
/share/qemu/QEMU,cgthree.bin
/share/qemu/qemu-icon.bmp
/share/qemu/qemu_logo_no_text.svg
/share/qemu/QEMU,tcx.bin
/share/qemu/s390-ccw.img
/share/qemu/s390-zipl.rom
/share/qemu/sgabios.bin
/share/qemu/slof.bin
/share/qemu/spapr-rtas.bin
/share/qemu/vgabios.bin
/share/qemu/vgabios-cirrus.bin
/share/qemu/vgabios-qxl.bin
/share/qemu/vgabios-stdvga.bin
/share/qemu/vgabios-vmware.bin
/sys
/tmp
/usr
/usr/lib -> /lib
/usr/lib64
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 4/7] libxl: Add "stubdomain_version" to domain_build_info.
2015-02-09 9:11 ` Ian Campbell
@ 2015-02-09 14:11 ` Eric Shelton
0 siblings, 0 replies; 43+ messages in thread
From: Eric Shelton @ 2015-02-09 14:11 UTC (permalink / raw)
To: Ian Campbell; +Cc: Anthony PERARD, xen-devel, Stefano Stabellini
On Mon, Feb 9, 2015 at 4:11 AM, Ian Campbell <ian.campbell@citrix.com> wrote:
> On Tue, 2015-02-03 at 23:06 -0500, Eric Shelton wrote:
>> This enum gives the ability to select between a MiniOS-based QEMU
>> traditional stub domain and a Linux-based QEMU upstream stub domain. To
>> use the Linux-based stubdomain, the following two lines should be
>> included in the appropriate xl.cfg file:
>>
>> device_model_version="qemu-xen"
>> device_model_stubdomain_override=1
>>
>> To use the MiniOS-based stubdomain, the following is used instead:
>>
>> device_model_version="qemu-xen-traditional"
>> device_model_stubdomain_override=1
>
> This doesn't seem to use this new stubdom_version option and I'm not
> really sure what it is for.
>
> Perhaps you meant this new thing to be a libxl internal Enum, rather
> than exposed to the application which is using libxl?
I believe Anthony's first patchset made this an explicit option for
xl.cfg (e.g., 'stubdom_version="linux"'), and then the second patchset
continued to use it internally, with the combination of
device_model_stubdomain_override and device_model_version setting its
value. I suppose the main benefit of this approach is if we foresee
more than one stubdom flavor for QEMU-upstream, but we're nowhere near
that.
> I'm not sure wy
> the user would need to be given the choice -- it should be inherent in
> the device-model version and stubdom boolean selection.
In effect, that is how it works - as illustrated by the two xl.cfg
examples above.
Perhaps it is best to just eliminate the internal enum, and have the
code just look to device_model_version. It has not been a good sign
that both Stephano (at least initially) and you have negatively
reacted to how it is currently being done.
- Eric
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 2/7] linux-stubdomain: Compile Linux
2015-02-06 17:45 ` Stefano Stabellini
2015-02-09 9:09 ` Ian Campbell
@ 2015-05-14 9:08 ` George Dunlap
2015-05-14 9:28 ` Ian Campbell
1 sibling, 1 reply; 43+ messages in thread
From: George Dunlap @ 2015-05-14 9:08 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Anthony PERARD, xen-devel, Ian Campbell, Eric Shelton
On Fri, Feb 6, 2015 at 5:45 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
>> >> +LINUX_URL=ftp://ftp.kernel.org/pub/linux/kernel/v3.x/$(LINUX_V).tar.xz
>> >> +
>> >> +all: $(VMLINUZ)
>> >
>> > I think it is best if we git clone it.
>>
>> Is that still true if unpatched 3.18.6 works? I don't know if there
>> is a desire to reduce load on kernel.org, for example.
>
> That's a good point. I think git clone would be more inline with any
> other external project that we use. However I'll let the other
> maintainers decide on this.
It takes a *loooooooong* time to download a full Linux git tree, and
it takes up a huge amount of disk space. It would be a lot more
convenient to be able to just download a tarball.
-George
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 2/7] linux-stubdomain: Compile Linux
2015-05-14 9:08 ` George Dunlap
@ 2015-05-14 9:28 ` Ian Campbell
2015-05-18 10:37 ` George Dunlap
0 siblings, 1 reply; 43+ messages in thread
From: Ian Campbell @ 2015-05-14 9:28 UTC (permalink / raw)
To: George Dunlap; +Cc: Anthony PERARD, Eric Shelton, xen-devel, Stefano Stabellini
On Thu, 2015-05-14 at 10:08 +0100, George Dunlap wrote:
> On Fri, Feb 6, 2015 at 5:45 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> >> >> +LINUX_URL=ftp://ftp.kernel.org/pub/linux/kernel/v3.x/$(LINUX_V).tar.xz
> >> >> +
> >> >> +all: $(VMLINUZ)
> >> >
> >> > I think it is best if we git clone it.
> >>
> >> Is that still true if unpatched 3.18.6 works? I don't know if there
> >> is a desire to reduce load on kernel.org, for example.
> >
> > That's a good point. I think git clone would be more inline with any
> > other external project that we use. However I'll let the other
> > maintainers decide on this.
>
> It takes a *loooooooong* time to download a full Linux git tree, and
> it takes up a huge amount of disk space. It would be a lot more
> convenient to be able to just download a tarball.
git clone --depth=<some small N> to create a shallow clone?
Ian.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 2/7] linux-stubdomain: Compile Linux
2015-05-14 9:28 ` Ian Campbell
@ 2015-05-18 10:37 ` George Dunlap
2015-05-18 10:45 ` Ian Campbell
0 siblings, 1 reply; 43+ messages in thread
From: George Dunlap @ 2015-05-18 10:37 UTC (permalink / raw)
To: Ian Campbell; +Cc: Anthony PERARD, xen-devel, Stefano Stabellini, Eric Shelton
On Thu, May 14, 2015 at 10:28 AM, Ian Campbell <ian.campbell@citrix.com> wrote:
> On Thu, 2015-05-14 at 10:08 +0100, George Dunlap wrote:
>> On Fri, Feb 6, 2015 at 5:45 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> >> >> +LINUX_URL=ftp://ftp.kernel.org/pub/linux/kernel/v3.x/$(LINUX_V).tar.xz
>> >> >> +
>> >> >> +all: $(VMLINUZ)
>> >> >
>> >> > I think it is best if we git clone it.
>> >>
>> >> Is that still true if unpatched 3.18.6 works? I don't know if there
>> >> is a desire to reduce load on kernel.org, for example.
>> >
>> > That's a good point. I think git clone would be more inline with any
>> > other external project that we use. However I'll let the other
>> > maintainers decide on this.
>>
>> It takes a *loooooooong* time to download a full Linux git tree, and
>> it takes up a huge amount of disk space. It would be a lot more
>> convenient to be able to just download a tarball.
>
> git clone --depth=<some small N> to create a shallow clone?
So my unscientific poll (more details below)
1. Download tarball: 80MB, 111s (<2m)
2. git clone --depth 1: 138MiB, 392s. (~6m30s)
I'd just go for the tarball, but I'll leave that decision up to you guys.
-George
$ time wget ftp://ftp.kernel.org/pub/linux/kernel/v3.x/linux-3.18.8.tar.xz
--2015-05-18 11:12:05--
ftp://ftp.kernel.org/pub/linux/kernel/v3.x/linux-3.18.8.tar.xz
=> ‘linux-3.18.8.tar.xz’
Resolving ftp.kernel.org (ftp.kernel.org)... 199.204.44.194,
149.20.4.69, 198.145.20.140
Connecting to ftp.kernel.org (ftp.kernel.org)|199.204.44.194|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD (1) /pub/linux/kernel/v3.x ... done.
==> SIZE linux-3.18.8.tar.xz ... 80954240
==> PASV ... done. ==> RETR linux-3.18.8.tar.xz ... done.
Length: 80954240 (77M) (unauthoritative)
100%[=====================================================================================================================================================================================================>]
80,954,240 723KB/s in 1m 51s
2015-05-18 11:13:57 (711 KB/s) - ‘linux-3.18.8.tar.xz’ saved [80954240]
real 1m52.548s
user 0m0.318s
sys 0m1.894s
$ time git clone --depth 1 --branch v3.18
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Cloning into 'linux'...
remote: Counting objects: 50728, done.
remote: Compressing objects: 100% (48908/48908), done.
remote: Total 50728 (delta 3388), reused 21833 (delta 1202)
Receiving objects: 100% (50728/50728), 138.44 MiB | 269.00 KiB/s, done.
Resolving deltas: 100% (3388/3388), done.
Checking connectivity... done.
Note: checking out 'b2776bf7149bddd1f4161f14f79520f17fc1d71d'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b new_branch_name
Checking out files: 100% (47986/47986), done.
real 6m32.968s
user 0m11.522s
sys 0m4.815s
>
> Ian.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 2/7] linux-stubdomain: Compile Linux
2015-05-18 10:37 ` George Dunlap
@ 2015-05-18 10:45 ` Ian Campbell
2015-05-18 10:55 ` George Dunlap
0 siblings, 1 reply; 43+ messages in thread
From: Ian Campbell @ 2015-05-18 10:45 UTC (permalink / raw)
To: George Dunlap; +Cc: Anthony PERARD, xen-devel, Stefano Stabellini, Eric Shelton
On Mon, 2015-05-18 at 11:37 +0100, George Dunlap wrote:
> So my unscientific poll (more details below)
>
> 1. Download tarball: 80MB, 111s (<2m)
>
> 2. git clone --depth 1: 138MiB, 392s. (~6m30s)
>
> I'd just go for the tarball, but I'll leave that decision up to you guys.
TBH I don't think we should accept either of those in xen.git.
The way to pursue Linux stubdomains further would seem to be via Raisin
anyway.
Ian.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 2/7] linux-stubdomain: Compile Linux
2015-05-18 10:45 ` Ian Campbell
@ 2015-05-18 10:55 ` George Dunlap
0 siblings, 0 replies; 43+ messages in thread
From: George Dunlap @ 2015-05-18 10:55 UTC (permalink / raw)
To: Ian Campbell; +Cc: Anthony PERARD, xen-devel, Stefano Stabellini, Eric Shelton
On 05/18/2015 11:45 AM, Ian Campbell wrote:
> On Mon, 2015-05-18 at 11:37 +0100, George Dunlap wrote:
>> So my unscientific poll (more details below)
>>
>> 1. Download tarball: 80MB, 111s (<2m)
>>
>> 2. git clone --depth 1: 138MiB, 392s. (~6m30s)
>>
>> I'd just go for the tarball, but I'll leave that decision up to you guys.
>
> TBH I don't think we should accept either of those in xen.git.
>
> The way to pursue Linux stubdomains further would seem to be via Raisin
> anyway.
+1
-G
^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2015-05-18 10:55 UTC | newest]
Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-04 4:06 [RFC 0/7] RFC Linux-based QEMU-upstream stub domain Eric Shelton
2015-02-04 4:06 ` [RFC 1/7] linux-stubdomain: Compile QEMU Eric Shelton
2015-02-06 15:46 ` Stefano Stabellini
2015-02-06 17:25 ` Eric Shelton
2015-02-06 17:27 ` Stefano Stabellini
2015-02-06 18:57 ` Wei Liu
2015-02-04 4:06 ` [RFC 2/7] linux-stubdomain: Compile Linux Eric Shelton
2015-02-06 15:51 ` Stefano Stabellini
2015-02-06 17:42 ` Eric Shelton
2015-02-06 17:45 ` Stefano Stabellini
2015-02-09 9:09 ` Ian Campbell
2015-05-14 9:08 ` George Dunlap
2015-05-14 9:28 ` Ian Campbell
2015-05-18 10:37 ` George Dunlap
2015-05-18 10:45 ` Ian Campbell
2015-05-18 10:55 ` George Dunlap
2015-02-04 4:06 ` [RFC 3/7] linux-stubdomain: Build a disk image Eric Shelton
2015-02-06 15:57 ` Stefano Stabellini
2015-02-06 17:45 ` Eric Shelton
2015-02-04 4:06 ` [RFC 4/7] libxl: Add "stubdomain_version" to domain_build_info Eric Shelton
2015-02-06 16:06 ` Stefano Stabellini
2015-02-06 17:50 ` Eric Shelton
2015-02-06 17:54 ` Stefano Stabellini
2015-02-09 9:11 ` Ian Campbell
2015-02-09 14:11 ` Eric Shelton
2015-02-04 4:06 ` [RFC 5/7] libxl: Handle Linux stubdomain specific QEMU options Eric Shelton
2015-02-06 16:17 ` Stefano Stabellini
2015-02-04 4:06 ` [RFC 6/7] libxl: Build the domain with a Linux based stubdomain Eric Shelton
2015-02-06 16:33 ` Stefano Stabellini
2015-02-04 4:06 ` [RFC 7/7] libxl: Wait for QEMU startup in stubdomain Eric Shelton
2015-02-06 11:16 ` Wei Liu
2015-02-06 13:56 ` Eric Shelton
2015-02-06 14:59 ` Wei Liu
2015-02-06 15:36 ` Stefano Stabellini
2015-02-06 17:10 ` Eric Shelton
2015-02-06 17:23 ` Stefano Stabellini
2015-02-09 9:07 ` Ian Campbell
2015-02-09 9:14 ` Stefano Stabellini
2015-02-09 12:08 ` Anthony PERARD
2015-02-09 13:57 ` Eric Shelton
2015-02-06 15:46 ` Eric Shelton
2015-02-06 16:12 ` Wei Liu
2015-02-06 15:42 ` [RFC 0/7] RFC Linux-based QEMU-upstream stub domain 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.