[Qemu-devel] [RFC PATCH V4 0/2] Support xen HVM direct kernel boot

[Qemu-devel] [RFC PATCH V4 0/2] Support xen HVM direct kernel boot

[Chunyan Liu]

Updated current patch series for working with qemu-xen and default
BIOS (seabios), to make it in good shape. Stubdom support will be
continued.
  
xen side patch: pass kernel/initrd/append parameters to qemu-dm
qemu side patch: reuse load_linux() for xen hvm direct kernel boot.
    Different from pc_memory_init which does lots of ram alloc work
    and rom/bios loading work, for xen, we only need to init a basic
    fw_cfg device used by load_linux() to store ADDRs and
    linuxboot.bin/multiboot.bin to retrive ADDRs, then load_linux(),
    after that, do real add option rom work to add
    linuxboot.bin/multiboot.bin to system option rom. Other things
    would be done by seabios smoothly.

Changes:
  xen side patch:
  - address to Ian J's comments:
    - drop 'cmdline' replacing 'root' and 'extra' implementation
      introduced in v3.
    - move 'kernel','ramdisk','cmdline' to libxl_domain_build_info
      common areas, rather then adding to .u.hvm.
    - update libxl.h to indicate the new changes
  qemu side patch:
  - add assertion
  - add description about vapic changes.

v3 is here:
https://lists.nongnu.org/archive/html/qemu-devel/2014-06/msg04903.html

v2 is here:
http://thread.gmane.org/gmane.comp.emulators.qemu/277514

v1 is here:
http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg06233.html

Chunyan Liu (2):
  xen: pass kernel initrd to qemu
  qemu: support xen HVM direct kernel boot

-- 
1.8.4.5

[Qemu-devel] [RFC PATCH V4 1/2] xen: pass kernel initrd to qemu

[Chunyan Liu]

xen side patch to support xen HVM direct kernel boot:
support 'kernel', 'ramdisk', 'cmdline' (and 'root', 'extra' as well
which would be deprecated later) in HVM config file, parse config file,
pass -kernel, -initrd, -append parameters to qemu.

It's working with qemu-xen when using the default BIOS (seabios).

[config example]
kernel="/mnt/vmlinuz-3.0.13-0.27-default"
ramdisk="/mnt/initrd-3.0.13-0.27-default"
root="/dev/hda2"
extra="console=tty0 console=ttyS0"

Signed-off-by: Chunyan Liu <cyliu@suse.com>
---
Changes to v3:
  address to Ian J's comments:
  - 'root' and 'extra' might be useful for future
    extension, so drop 'cmdline' replacing 'root' and 'extra'
    implementation introduced in v3, keep existing way.
  - move 'kernel','ramdisk','cmdline' to libxl_domain_build_info common
    areas, rather then adding to .u.hvm. But for compatibility, keep
    .u.pv.kernel, .u.pv.ramdisk, .u.pv.cmdline.
  - update libxl.h to indicate the new changes: add
    LIBXL_HAVE_BUILDINFO_KERNEL
    LIBXL_HAVE_BUILDINFO_RAMDISK 
    LIBXL_HAVE_BUILDINFO_CMDLINE
  - update description in man page to make it more clear

 docs/man/xl.cfg.pod.5       | 53 +++++++++++++++++++++++++----------------
 tools/libxl/libxl.h         | 38 ++++++++++++++++++++++++++++++
 tools/libxl/libxl_dm.c      | 15 ++++++++++++
 tools/libxl/libxl_types.idl |  3 +++
 tools/libxl/xl_cmdimpl.c    | 57 ++++++++++++++++++++++++++++-----------------
 5 files changed, 124 insertions(+), 42 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index c087cbc..5833908 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -304,6 +304,37 @@ Action to take if the domain crashes.  Default is C<destroy>.
 
 =back
 
+=head3 Direct Kernel Boot
+
+Direct kernel boot allows booting directly from a kernel and initrd
+stored in the host physical machine OS, allowing command line arguments
+to be passed directly. PV guest direct kernel boot is supported. HVM
+guest direct kernel boot is supported with limitation (it's supported
+when using qemu-xen and default BIOS 'seabios'; not supported in case of
+stubdom-dm and old rombios.)
+
+=over 4
+
+=item B<kernel="PATHNAME">
+
+Load the specified file as the kernel image.
+
+=item B<ramdisk="PATHNAME">
+
+Load the specified file as the ramdisk.
+
+=item B<root="STRING">
+
+Append B<root="STRING"> to the kernel command line (Note: it is guest
+specific what meaning this has).
+
+=item B<extra="STRING">
+
+Append B<STRING> to the kernel command line. (Note: it is guest
+specific what meaning this has).
+
+=back
+
 =head3 Other Options
 
 =over 4
@@ -646,20 +677,12 @@ The following options apply only to Paravirtual guests.
 
 =over 4
 
-=item B<kernel="PATHNAME">
-
-Load the specified file as the kernel image.  Either B<kernel> or
-B<bootloader> must be specified for PV guests.
-
-=item B<ramdisk="PATHNAME">
-
-Load the specified file as the ramdisk.
-
 =item B<bootloader="PROGRAM">
 
 Run C<PROGRAM> to find the kernel image and ramdisk to use.  Normally
 C<PROGRAM> would be C<pygrub>, which is an emulation of
-grub/grub2/syslinux.
+grub/grub2/syslinux. Either B<kernel> or B<bootloader> must be specified
+for PV guests.
 
 =item B<bootloader_args=[ "ARG", "ARG", ...]>
 
@@ -667,16 +690,6 @@ Append B<ARG>s to the arguments to the B<bootloader>
 program. Alternatively if the argument is a simple string then it will
 be split into words at whitespace (this second option is deprecated).
 
-=item B<root="STRING">
-
-Append B<root="STRING"> to the kernel command line (Note: it is guest
-specific what meaning this has).
-
-=item B<extra="STRING">
-
-Append B<STRING> to the kernel command line. Note: it is guest
-specific what meaning this has).
-
 =item B<e820_host=BOOLEAN>
 
 Selects whether to expose the host e820 (memory map) to the guest via
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 69ceac8..a45415d 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -493,6 +493,44 @@ typedef struct libxl__ctx libxl_ctx;
  */
 #define LIBXL_HAVE_DEVICE_PCI_SEIZE 1
 
+/*
+ * LIBXL_HAVE_BUILDINFO_KERNEL
+ *
+ * If this is defined, then the libxl_domain_build_info structure will
+ * contain 'kernel' string field. It is to indicate kernel image location,
+ * for both PV and HVM guest to do direct kernel boot. For compatibility,
+ * u.pv.kernel still exists, but it might be deprecated in future.
+ *
+ * If it is set, guest will be booted from the indicated kernel.
+ */
+#define LIBXL_HAVE_BUILDINFO_KERNEL 1
+
+/*
+ * LIBXL_HAVE_BUILDINFO_RAMDISK
+ *
+ * If this is defined, then the libxl_domain_build_info structure will
+ * contain 'ramdisk' string field. It is to indicate ramdisk location,
+ * for both PV and HVM guest to do direct kernel boot. For compatibility,
+ * u.pv.ramdisk still exists, but it might be deprecated in future.
+ *
+ * If it is set, guest will be booted from indicated kernel and ramdisk.
+ */
+#define LIBXL_HAVE_BUILDINFO_RAMDISK 1
+
+/*
+ * LIBXL_HAVE_BUILDINFO_CMDLINE
+ *
+ * If this is defined, then the libxl_domain_build_info structure will
+ * contain 'cmdline' string field. It is a string to indicate paramters
+ * which would be appened to kernel image, for both PV and HVM guest to
+ * do direct kernel boot. For compatibility, u.pv.cmdline still exists,
+ * but it might be deprecated in future.
+ *
+ * If it is set, guest will be booted from indicated kernel with
+ * parameters as indicated in 'cmdline'.
+ */
+#define LIBXL_HAVE_BUILDINFO_CMDLINE 1
+
 /* Functions annotated with LIBXL_EXTERNAL_CALLERS_ONLY may not be
  * called from within libxl itself. Callers outside libxl, who
  * do not #include libxl_internal.h, are fine. */
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index addacdb..4f1cbd2 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -196,6 +196,12 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
         int nr_set_cpus = 0;
         char *s;
 
+        if (b_info->kernel) {
+            LOG(ERROR, "HVM direct kernel boot is not supported by "
+                "qemu-xen-traditional");
+            return NULL;
+        }
+
         if (b_info->u.hvm.serial) {
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
         }
@@ -479,6 +485,15 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_nics = 0;
 
+        if (b_info->kernel)
+            flexarray_vappend(dm_args, "-kernel", b_info->kernel, NULL);
+
+        if (b_info->ramdisk)
+            flexarray_vappend(dm_args, "-initrd", b_info->ramdisk, NULL);
+
+        if (b_info->cmdline)
+            flexarray_vappend(dm_args, "-append", b_info->cmdline, NULL);
+
         if (b_info->u.hvm.serial) {
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
         }
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 1018142..66ba18b 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -338,6 +338,9 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("iomem",            Array(libxl_iomem_range, "num_iomem")),
     ("claim_mode",	     libxl_defbool),
     ("event_channels",   uint32),
+    ("kernel",           string),
+    ("cmdline",          string),
+    ("ramdisk",          string),
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware",         string),
                                        ("bios",             libxl_bios_type),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index be041f2..123d84d 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -693,6 +693,29 @@ static void parse_top_level_sdl_options(XLU_Config *config,
     xlu_cfg_replace_string (config, "xauthority", &sdl->xauthority, 0);
 }
 
+static char *parse_cmdline(XLU_Config *config)
+{
+    char *cmdline = NULL;
+    const char *root = NULL, *extra = "";
+
+    xlu_cfg_get_string (config, "root", &root, 0);
+    xlu_cfg_get_string (config, "extra", &extra, 0);
+
+    if (root) {
+        if (asprintf(&cmdline, "root=%s %s", root, extra) == -1)
+            cmdline = NULL;
+    } else {
+        cmdline = strdup(extra);
+    }
+
+    if ((root || extra) && !cmdline) {
+        fprintf(stderr, "Failed to allocate memory for cmdline\n");
+        exit(1);
+    }
+
+    return cmdline;
+}
+
 static void parse_config_data(const char *config_source,
                               const char *config_data,
                               int config_len,
@@ -942,13 +965,21 @@ static void parse_config_data(const char *config_source,
     if (!xlu_cfg_get_long(config, "max_event_channels", &l, 0))
         b_info->event_channels = l;
 
+    xlu_cfg_replace_string (config, "kernel", &b_info->kernel, 0);
+    xlu_cfg_replace_string (config, "ramdisk", &b_info->ramdisk, 0);
+    b_info->cmdline = parse_cmdline(config);
+
     xlu_cfg_get_defbool(config, "driver_domain", &c_info->driver_domain, 0);
 
     switch(b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        if (!xlu_cfg_get_string (config, "kernel", &buf, 0))
-            fprintf(stderr, "WARNING: ignoring \"kernel\" directive for HVM guest. "
-                    "Use \"firmware_override\" instead if you really want a non-default firmware\n");
+        if (!strcmp(libxl_basename(b_info->kernel), "hvmloader")) {
+            fprintf(stderr, "WARNING: you seem to be using \"kernel\" "
+                    "directive to override HVM guest firmware. Ignore "
+                    "that. Use \"firmware_override\" instead if you "
+                    "really want a non-default firmware\n");
+            b_info->kernel = NULL;
+        }
 
         xlu_cfg_replace_string (config, "firmware_override",
                                 &b_info->u.hvm.firmware, 0);
@@ -1000,26 +1031,8 @@ static void parse_config_data(const char *config_source,
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {
-        char *cmdline = NULL;
-        const char *root = NULL, *extra = "";
-
         xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel, 0);
 
-        xlu_cfg_get_string (config, "root", &root, 0);
-        xlu_cfg_get_string (config, "extra", &extra, 0);
-
-        if (root) {
-            if (asprintf(&cmdline, "root=%s %s", root, extra) == -1)
-                cmdline = NULL;
-        } else {
-            cmdline = strdup(extra);
-        }
-
-        if ((root || extra) && !cmdline) {
-            fprintf(stderr, "Failed to allocate memory for cmdline\n");
-            exit(1);
-        }
-
         xlu_cfg_replace_string (config, "bootloader", &b_info->u.pv.bootloader, 0);
         switch (xlu_cfg_get_list_as_string_list(config, "bootloader_args",
                                       &b_info->u.pv.bootloader_args, 1))
@@ -1047,7 +1060,7 @@ static void parse_config_data(const char *config_source,
             exit(1);
         }
 
-        b_info->u.pv.cmdline = cmdline;
+        b_info->u.pv.cmdline = parse_cmdline(config);
         xlu_cfg_replace_string (config, "ramdisk", &b_info->u.pv.ramdisk, 0);
         break;
     }
-- 
1.8.4.5

Re: [Qemu-devel] [RFC PATCH V4 1/2] xen: pass kernel initrd to qemu

[Ian Campbell]

On Tue, 2014-07-01 at 15:06 +0800, Chunyan Liu wrote:
> xen side patch to support xen HVM direct kernel boot:
> support 'kernel', 'ramdisk', 'cmdline' (and 'root', 'extra' as well
> which would be deprecated later) in HVM config file, parse config file,
> pass -kernel, -initrd, -append parameters to qemu.
> 
> It's working with qemu-xen when using the default BIOS (seabios).
> 
> [config example]
> kernel="/mnt/vmlinuz-3.0.13-0.27-default"
> ramdisk="/mnt/initrd-3.0.13-0.27-default"
> root="/dev/hda2"
> extra="console=tty0 console=ttyS0"
> 
> Signed-off-by: Chunyan Liu <cyliu@suse.com>
> ---
> Changes to v3:
>   address to Ian J's comments:
>   - 'root' and 'extra' might be useful for future
>     extension, so drop 'cmdline' replacing 'root' and 'extra'
>     implementation introduced in v3, keep existing way.
>   - move 'kernel','ramdisk','cmdline' to libxl_domain_build_info common
>     areas, rather then adding to .u.hvm. But for compatibility, keep
>     .u.pv.kernel, .u.pv.ramdisk, .u.pv.cmdline.

For compatibility you also need to propagate u.pv.* into the top level
options when they are set but the toplevel one isn't. The right place to
do this is probably libxl__domain_build_info_setdefaults.

The important thing is that applications which have not updated to the
new interface must continue to work.

> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 69ceac8..a45415d 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -493,6 +493,44 @@ typedef struct libxl__ctx libxl_ctx;
>   */
>  #define LIBXL_HAVE_DEVICE_PCI_SEIZE 1
>  
> +/*
> + * LIBXL_HAVE_BUILDINFO_KERNEL

In general we try and collapse multiple of these LIBXL_HAVE together if
the features were added at the same time. I think a single
LIBLX_HAVE_BUILDINFO_KERNEL or so to cover kernel, ramdisk and cmdline
would do.

> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index be041f2..123d84d 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -693,6 +693,29 @@ static void parse_top_level_sdl_options(XLU_Config *config,
>      xlu_cfg_replace_string (config, "xauthority", &sdl->xauthority, 0);
>  }
>  
> +static char *parse_cmdline(XLU_Config *config)
> +{
> +    char *cmdline = NULL;
> +    const char *root = NULL, *extra = "";
> +
> +    xlu_cfg_get_string (config, "root", &root, 0);
> +    xlu_cfg_get_string (config, "extra", &extra, 0);

I see you've dropped "cmdline" here, presumably because of Ian J's
comments. Sorry that we are disagreeing here with you caught in the
middle.

I still think cmdline= is a good improvement, but I suggest you wait
until Ian and I have agreed one way or the other before making any
change.

Sorry again.

Ian.

[Qemu-devel] [RFC PATCH V3 0/2] support xen HVM direct kernel boot

[Chunyan Liu]

Updated current patch series for working with qemu-xen and default
BIOS (seabios), to make it in good shape. Stubdom support will be
continued.

xen side patch: pass kernel/initrd/append parameters to qemu-dm
qemu side patch: reuse load_linux() for xen hvm direct kernel boot.
    Different from pc_memory_init which does lots of ram alloc work
    and rom/bios loading work, for xen, we only need to init a basic
    fw_cfg device used by load_linux() to store ADDRs and
    linuxboot.bin/multiboot.bin to retrive ADDRs, then load_linux(),
    after that, do real add option rom work to add
    linuxboot.bin/multiboot.bin to system option rom. Other things
    would be done by seabios smoothly.

Changes:
  xen side patch:
  - as Ian (C.) suggests, add 'cmdline' to config file,
    will replace old 'root' and 'extra' way.
  - fix other comments of Ian (C.)

v2 is here:
http://thread.gmane.org/gmane.comp.emulators.qemu/277514

v1 is here:
http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg06233.html

Chunyan Liu (2):
  xen: pass kernel initrd to qemu
  qemu: support xen hvm direct kernel boot

 docs/man/xl.cfg.pod.5       | 57 +++++++++++++++++++++++++--------------
 tools/libxl/libxl.h         | 13 +++++++++
 tools/libxl/libxl_dm.c      | 15 +++++++++++
 tools/libxl/libxl_types.idl |  3 +++
 tools/libxl/xl_cmdimpl.c    | 66 ++++++++++++++++++++++++++++++---------------
 5 files changed, 112 insertions(+), 42 deletions(-)

-- 
1.8.4.5

[Qemu-devel] [RFC PATCH V3 1/2] xen: pass kernel initrd to qemu

[Chunyan Liu]

xen side patch to support xen HVM direct kernel boot:
support 'kernel', 'ramdisk', 'cmdline' (and 'root', 'extra' as well
which would be deprecated later) in HVM config file, parse config file,
pass -kernel, -initrd, -append parameters to qemu.

It's working with qemu-xen when using the default BIOS (seabios).

[config example]
kernel="/mnt/vmlinuz-3.0.13-0.27-default"
ramdisk="/mnt/initrd-3.0.13-0.27-default"
cmdline="/dev/hda2 console=tty0 console=ttyS0"
or:
kernel="/mnt/vmlinuz-3.0.13-0.27-default"
ramdisk="/mnt/initrd-3.0.13-0.27-default"
root="/dev/hda2"
extra="console=tty0 console=ttyS0"

Signed-off-by: Chunyan Liu <cyliu@suse.com>
---
 docs/man/xl.cfg.pod.5       | 57 +++++++++++++++++++++++++--------------
 tools/libxl/libxl.h         | 13 +++++++++
 tools/libxl/libxl_dm.c      | 15 +++++++++++
 tools/libxl/libxl_types.idl |  3 +++
 tools/libxl/xl_cmdimpl.c    | 66 ++++++++++++++++++++++++++++++---------------
 5 files changed, 112 insertions(+), 42 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index a94d037..c460dd4 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -304,6 +304,41 @@ Action to take if the domain crashes.  Default is C<destroy>.
 
 =back
 
+=head3 Direct Kernel Boot
+
+Currently, direct kernel boot can be supported by PV guests, and HVM guests
+with limitations. For HVM guests, in case of stubdom-dm and old rombios,
+direct kernel boot is not supported.
+
+=over 4
+
+=item B<kernel="PATHNAME">
+
+Load the specified file as the kernel image.
+
+=item B<ramdisk="PATHNAME">
+
+Load the specified file as the ramdisk.
+
+=item B<cmdline="STRING">
+
+Append B<cmdline="STRING"> to the kernel command line. (Note: it is
+guest specific what meaning this has). It will replace
+B<root="STRING"> plus B<extra="STRING">. When B<cmdline="STRING"> is
+set, B<root="STRING"> and B<extra="STRING"> will be ignored.
+
+=item B<root="STRING">
+
+Append B<root="STRING"> to the kernel command line (Note: it is guest
+specific what meaning this has). It will be deprecated.
+
+=item B<extra="STRING">
+
+Append B<STRING> to the kernel command line. (Note: it is guest
+specific what meaning this has). It will be deprecated.
+
+=back
+
 =head3 Other Options
 
 =over 4
@@ -646,20 +681,12 @@ The following options apply only to Paravirtual guests.
 
 =over 4
 
-=item B<kernel="PATHNAME">
-
-Load the specified file as the kernel image.  Either B<kernel> or
-B<bootloader> must be specified for PV guests.
-
-=item B<ramdisk="PATHNAME">
-
-Load the specified file as the ramdisk.
-
 =item B<bootloader="PROGRAM">
 
 Run C<PROGRAM> to find the kernel image and ramdisk to use.  Normally
 C<PROGRAM> would be C<pygrub>, which is an emulation of
-grub/grub2/syslinux.
+grub/grub2/syslinux. Either B<kernel> or B<bootloader> must be specified
+for PV guests.
 
 =item B<bootloader_args=[ "ARG", "ARG", ...]>
 
@@ -667,16 +694,6 @@ Append B<ARG>s to the arguments to the B<bootloader>
 program. Alternatively if the argument is a simple string then it will
 be split into words at whitespace (this second option is deprecated).
 
-=item B<root="STRING">
-
-Append B<root="STRING"> to the kernel command line (Note: it is guest
-specific what meaning this has).
-
-=item B<extra="STRING">
-
-Append B<STRING> to the kernel command line. Note: it is guest
-specific what meaning this has).
-
 =item B<e820_host=BOOLEAN>
 
 Selects whether to expose the host e820 (memory map) to the guest via
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 80947c3..0ef393e 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -482,6 +482,19 @@
  */
 #define LIBXL_HAVE_DEVICE_PCI_SEIZE 1
 
+/*
+ * LIBXL_HAVE_BUILDINFO_HVM_DIRECT_KERNEL_BOOT
+ *
+ * If this is defined, then the libxl_domain_build_info structure will
+ * contain hvm.kernel, hvm.cmdline and hvm.ramdisk. hvm.kernel is a string
+ * to indicate kernel image location, hvm.ramdisk is a string to indicate
+ * ramdisk location, hvm.cmdline is a string to indicate the paramters which
+ * would be appened to kernel image.
+ *
+ * If it is set, guest will be booted from the indicated kernel and ramdisk.
+ */
+#define LIBXL_HAVE_BUILDINFO_HVM_DIRECT_KERNEL_BOOT 1
+
 /* Functions annotated with LIBXL_EXTERNAL_CALLERS_ONLY may not be
  * called from within libxl itself. Callers outside libxl, who
  * do not #include libxl_internal.h, are fine. */
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 51ab2bf..fe53441 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -196,6 +196,12 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
         int nr_set_cpus = 0;
         char *s;
 
+        if (b_info->u.hvm.kernel) {
+            LOG(ERROR, "direct kernel boot is not supported by "
+                "qemu-xen-traditional");
+            return NULL;
+        }
+
         if (b_info->u.hvm.serial) {
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
         }
@@ -479,6 +485,15 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_nics = 0;
 
+        if (b_info->u.hvm.kernel)
+            flexarray_vappend(dm_args, "-kernel", b_info->u.hvm.kernel, NULL);
+
+        if (b_info->u.hvm.ramdisk)
+            flexarray_vappend(dm_args, "-initrd", b_info->u.hvm.ramdisk, NULL);
+
+        if (b_info->u.hvm.cmdline)
+            flexarray_vappend(dm_args, "-append", b_info->u.hvm.cmdline, NULL);
+
         if (b_info->u.hvm.serial) {
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
         }
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 52f1aa9..a96b228 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -336,6 +336,9 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("event_channels",   uint32),
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware",         string),
+                                       ("kernel",           string),
+                                       ("cmdline",          string),
+                                       ("ramdisk",          string),
                                        ("bios",             libxl_bios_type),
                                        ("pae",              libxl_defbool),
                                        ("apic",             libxl_defbool),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 5195914..a31e8c6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -725,6 +725,37 @@ static void parse_top_level_sdl_options(XLU_Config *config,
     xlu_cfg_replace_string (config, "xauthority", &sdl->xauthority, 0);
 }
 
+static char *parse_cmdline(XLU_Config *config)
+{
+    char *cmdline = NULL;
+    const char *root = NULL, *extra = NULL, *buf = NULL;
+
+    xlu_cfg_get_string (config, "cmdline", &buf, 0);
+    xlu_cfg_get_string (config, "root", &root, 0);
+    xlu_cfg_get_string (config, "extra", &extra, 0);
+
+    if (buf) {
+        cmdline = strdup(buf);
+        if (root || extra)
+            fprintf(stderr, "Warning: ignoring deprecated root= and extra= "
+                    "in favour of cmdline=\n");
+    } else {
+        if (root) {
+            if (asprintf(&cmdline, "root=%s %s", root, extra) == -1)
+                cmdline = NULL;
+        } else if (extra) {
+            cmdline = strdup(extra);
+        }
+    }
+
+    if ((buf || root || extra) && !cmdline) {
+        fprintf(stderr, "Failed to allocate memory for cmdline\n");
+        exit(1);
+    }
+
+    return cmdline;
+}
+
 static void parse_config_data(const char *config_source,
                               const char *config_data,
                               int config_len,
@@ -1007,9 +1038,18 @@ static void parse_config_data(const char *config_source,
 
     switch(b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        if (!xlu_cfg_get_string (config, "kernel", &buf, 0))
-            fprintf(stderr, "WARNING: ignoring \"kernel\" directive for HVM guest. "
-                    "Use \"firmware_override\" instead if you really want a non-default firmware\n");
+        if (!xlu_cfg_get_string (config, "kernel", &buf, 0)) {
+            if (!strcmp(libxl_basename(buf), "hvmloader"))
+                fprintf(stderr, "WARNING: you seem to be using \"kernel\" "
+                        "directive to override HVM guest firmware. Ignore "
+                        "that. Use \"firmware_override\" instead if you "
+                        "really want a non-default firmware\n");
+            else
+                b_info->u.hvm.kernel = strdup(buf);
+        }
+
+        b_info->u.hvm.cmdline = parse_cmdline(config);
+        xlu_cfg_replace_string (config, "ramdisk", &b_info->u.hvm.ramdisk, 0);
 
         xlu_cfg_replace_string (config, "firmware_override",
                                 &b_info->u.hvm.firmware, 0);
@@ -1061,26 +1101,8 @@ static void parse_config_data(const char *config_source,
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {
-        char *cmdline = NULL;
-        const char *root = NULL, *extra = "";
-
         xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel, 0);
 
-        xlu_cfg_get_string (config, "root", &root, 0);
-        xlu_cfg_get_string (config, "extra", &extra, 0);
-
-        if (root) {
-            if (asprintf(&cmdline, "root=%s %s", root, extra) == -1)
-                cmdline = NULL;
-        } else {
-            cmdline = strdup(extra);
-        }
-
-        if ((root || extra) && !cmdline) {
-            fprintf(stderr, "Failed to allocate memory for cmdline\n");
-            exit(1);
-        }
-
         xlu_cfg_replace_string (config, "bootloader", &b_info->u.pv.bootloader, 0);
         switch (xlu_cfg_get_list_as_string_list(config, "bootloader_args",
                                       &b_info->u.pv.bootloader_args, 1))
@@ -1108,7 +1130,7 @@ static void parse_config_data(const char *config_source,
             exit(1);
         }
 
-        b_info->u.pv.cmdline = cmdline;
+        b_info->u.pv.cmdline = parse_cmdline(config);
         xlu_cfg_replace_string (config, "ramdisk", &b_info->u.pv.ramdisk, 0);
         break;
     }
-- 
1.8.4.5

Re: [Qemu-devel] [RFC PATCH V3 1/2] xen: pass kernel initrd to qemu

[Ian Jackson]

Chunyan Liu writes ("[RFC PATCH V3 1/2] xen: pass kernel initrd to qemu"):
> xen side patch to support xen HVM direct kernel boot:
> support 'kernel', 'ramdisk', 'cmdline' (and 'root', 'extra' as well
> which would be deprecated later) in HVM config file, parse config file,
> pass -kernel, -initrd, -append parameters to qemu.
...
> +Currently, direct kernel boot can be supported by PV guests, and HVM guests
> +with limitations. For HVM guests, in case of stubdom-dm and old rombios,
> +direct kernel boot is not supported.

What does "PV guests" mean here ?  Do you mean guest kernels which
support the Xen PV environment ?

If so, what is the benefit of booting them "direct" but HVM, rather
than simply booting them PV ?

>  =item B<bootloader="PROGRAM">
>  
>  Run C<PROGRAM> to find the kernel image and ramdisk to use.  Normally
>  C<PROGRAM> would be C<pygrub>, which is an emulation of
> -grub/grub2/syslinux.
> +grub/grub2/syslinux. Either B<kernel> or B<bootloader> must be specified
> +for PV guests.

Surely using this should be possible for direct kernel boot too.

> +/*
> + * LIBXL_HAVE_BUILDINFO_HVM_DIRECT_KERNEL_BOOT
> + *
> + * If this is defined, then the libxl_domain_build_info structure will
> + * contain hvm.kernel, hvm.cmdline and hvm.ramdisk. hvm.kernel is a string
> + * to indicate kernel image location, hvm.ramdisk is a string to indicate
> + * ramdisk location, hvm.cmdline is a string to indicate the paramters which
> + * would be appened to kernel image.

If we are going to do this then I think the kernel, cmdline and
ramdisk (and bootloader) parameters shoudl be moved into the main part
of the domain_build_info struct.  This will involve a compatibility
layer: temporarily (for at least one release) both will be supported
so the IDL will have to have both and code inside libxl will have to
honour either.

The #define should then be
  LIBXL_HAVE_BUILD_INFO_CMDLINE
or some such - because all libxl callers will want to update to the
  new API eventually.

> +static char *parse_cmdline(XLU_Config *config)
> +{
> +    char *cmdline = NULL;
> +    const char *root = NULL, *extra = NULL, *buf = NULL;
> +
> +    xlu_cfg_get_string (config, "cmdline", &buf, 0);
> +    xlu_cfg_get_string (config, "root", &root, 0);
> +    xlu_cfg_get_string (config, "extra", &extra, 0);
> +
> +    if (buf) {
> +        cmdline = strdup(buf);
> +        if (root || extra)
> +            fprintf(stderr, "Warning: ignoring deprecated root= and extra= "
> +                    "in favour of cmdline=\n");

Why are you deprecating root= and extra= ?

They seem likely to be a useful distinction if we decide to add
further default options in the future.

If you do want to deprecate them, you should make this very clear -
probably by putting that change in a separate patch in your series.

Thanks,
Ian.

Re: [Qemu-devel] [Xen-devel] [RFC PATCH V3 1/2] xen: pass kernel initrd to qemu

[Chun Yan Liu]

>>> On 6/23/2014 at 10:22 PM, in message
<21416.14398.695327.278606@mariner.uk.xensource.com>, Ian Jackson
<Ian.Jackson@eu.citrix.com> wrote: 
> Chunyan Liu writes ("[RFC PATCH V3 1/2] xen: pass kernel initrd to qemu"): 
> > xen side patch to support xen HVM direct kernel boot: 
> > support 'kernel', 'ramdisk', 'cmdline' (and 'root', 'extra' as well 
> > which would be deprecated later) in HVM config file, parse config file, 
> > pass -kernel, -initrd, -append parameters to qemu. 
> ... 
> > +Currently, direct kernel boot can be supported by PV guests, and HVM  
> guests 
> > +with limitations. For HVM guests, in case of stubdom-dm and old rombios, 
> > +direct kernel boot is not supported. 
>  
> What does "PV guests" mean here ?  Do you mean guest kernels which 
> support the Xen PV environment ? 

Yes. I mean Paravirtualized Guest.
Since before this patch these options are supported by PV guest only (to do
direct kernel boot), now HVM guest also supports them, so I move them to the
general options. What I want to say here is:
PV guests can support direct kernel boot (as always), now HVM guests can
support direct kernel boot too but with limitations (qemu-xen with default
seabios).

>  
> If so, what is the benefit of booting them "direct" but HVM, rather 
> than simply booting them PV ? 
>  
> >  =item B<bootloader="PROGRAM"> 
> >   
> >  Run C<PROGRAM> to find the kernel image and ramdisk to use.  Normally 
> >  C<PROGRAM> would be C<pygrub>, which is an emulation of 
> > -grub/grub2/syslinux. 
> > +grub/grub2/syslinux. Either B<kernel> or B<bootloader> must be specified 
> > +for PV guests. 
>  
> Surely using this should be possible for direct kernel boot too. 
>  
> > +/* 
> > + * LIBXL_HAVE_BUILDINFO_HVM_DIRECT_KERNEL_BOOT 
> > + * 
> > + * If this is defined, then the libxl_domain_build_info structure will 
> > + * contain hvm.kernel, hvm.cmdline and hvm.ramdisk. hvm.kernel is a string 
> > + * to indicate kernel image location, hvm.ramdisk is a string to indicate 
> > + * ramdisk location, hvm.cmdline is a string to indicate the paramters  
> which 
> > + * would be appened to kernel image. 
>  
> If we are going to do this then I think the kernel, cmdline and 
> ramdisk (and bootloader) parameters shoudl be moved into the main part 
> of the domain_build_info struct.  This will involve a compatibility 
> layer: temporarily (for at least one release) both will be supported 
> so the IDL will have to have both and code inside libxl will have to 
> honour either. 

I see.

>  
> The #define should then be 
>   LIBXL_HAVE_BUILD_INFO_CMDLINE 
> or some such - because all libxl callers will want to update to the 
>   new API eventually. 
>  
> > +static char *parse_cmdline(XLU_Config *config) 
> > +{ 
> > +    char *cmdline = NULL; 
> > +    const char *root = NULL, *extra = NULL, *buf = NULL; 
> > + 
> > +    xlu_cfg_get_string (config, "cmdline", &buf, 0); 
> > +    xlu_cfg_get_string (config, "root", &root, 0); 
> > +    xlu_cfg_get_string (config, "extra", &extra, 0); 
> > + 
> > +    if (buf) { 
> > +        cmdline = strdup(buf); 
> > +        if (root || extra) 
> > +            fprintf(stderr, "Warning: ignoring deprecated root= and extra=  
> " 
> > +                    "in favour of cmdline=\n"); 
>  
> Why are you deprecating root= and extra= ? 

Just following Ian Campbell's suggestion:
http://lists.gnu.org/archive/html/qemu-devel/2014-06/msg02909.html
Now, cmdline is actually 'root' plus 'extra', if there is no special future usage,
one 'cmdline' seems to be better.

> 
> They seem likely to be a useful distinction if we decide to add 
> further default options in the future. 

Don't know how they will be used. But it we do need them, sure we can keep
the current way.

Thanks,
Chunyan

>  
> If you do want to deprecate them, you should make this very clear - 
> probably by putting that change in a separate patch in your series. 
>  
> Thanks, 
> Ian. 
>  
> _______________________________________________ 
> Xen-devel mailing list 
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 
>  
>  

Re: [Qemu-devel] [RFC PATCH V3 1/2] xen: pass kernel initrd to qemu

[Ian Campbell]

On Mon, 2014-06-23 at 15:22 +0100, Ian Jackson wrote:
> > +/*
> > + * LIBXL_HAVE_BUILDINFO_HVM_DIRECT_KERNEL_BOOT
> > + *
> > + * If this is defined, then the libxl_domain_build_info structure will
> > + * contain hvm.kernel, hvm.cmdline and hvm.ramdisk. hvm.kernel is a string
> > + * to indicate kernel image location, hvm.ramdisk is a string to indicate
> > + * ramdisk location, hvm.cmdline is a string to indicate the paramters which
> > + * would be appened to kernel image.
> 
> If we are going to do this then I think the kernel, cmdline and
> ramdisk (and bootloader) parameters shoudl be moved into the main part
> of the domain_build_info struct.  This will involve a compatibility
> layer: temporarily (for at least one release)

I don't think so -- we would need to retain it forever or at least until
some sort of "API break" event. We still guarantee that applications
using the 4.2 API will be supported.

>  both will be supported
> so the IDL will have to have both and code inside libxl will have to
> honour either.
> 
> The #define should then be
>   LIBXL_HAVE_BUILD_INFO_CMDLINE
> or some such - because all libxl callers will want to update to the
>   new API eventually.
> 
> > +static char *parse_cmdline(XLU_Config *config)
> > +{
> > +    char *cmdline = NULL;
> > +    const char *root = NULL, *extra = NULL, *buf = NULL;
> > +
> > +    xlu_cfg_get_string (config, "cmdline", &buf, 0);
> > +    xlu_cfg_get_string (config, "root", &root, 0);
> > +    xlu_cfg_get_string (config, "extra", &extra, 0);
> > +
> > +    if (buf) {
> > +        cmdline = strdup(buf);
> > +        if (root || extra)
> > +            fprintf(stderr, "Warning: ignoring deprecated root= and extra= "
> > +                    "in favour of cmdline=\n");
> 
> Why are you deprecating root= and extra= ?

I suggested this. They are suckful interfaces which expose Linux
specifics (e.g. the root= syntax) in our guest cfg files. cmdline is the
generic equivalent.

However, I didn't mean for them to not work, just that cmdline would be
preferred.

> They seem likely to be a useful distinction if we decide to add
> further default options in the future.
> 
> If you do want to deprecate them, you should make this very clear -
> probably by putting that change in a separate patch in your series.
> 
> Thanks,
> Ian.

Re: [Qemu-devel] [RFC PATCH V3 1/2] xen: pass kernel initrd to qemu [and 1 more messages]

[Ian Jackson]

Ian Campbell writes ("Re: [RFC PATCH V3 1/2] xen: pass kernel initrd to qemu"):
> On Mon, 2014-06-23 at 15:22 +0100, Ian Jackson wrote:
> > If we are going to do this then I think the kernel, cmdline and
> > ramdisk (and bootloader) parameters shoudl be moved into the main part
> > of the domain_build_info struct.  This will involve a compatibility
> > layer: temporarily (for at least one release)
> 
> I don't think so -- we would need to retain it forever or at least until
> some sort of "API break" event. We still guarantee that applications
> using the 4.2 API will be supported.

Yes.  Sorry, I meant that the compatibility should be retained for
some considerable time.  So for now we should honour all the existing
config struct members plus also the new cmdline member which should
IMO be in the main part of the struct and not inside pv.

> > Why are you deprecating root= and extra= ?
> 
> I suggested this. They are suckful interfaces which expose Linux
> specifics (e.g. the root= syntax) in our guest cfg files. cmdline is the
> generic equivalent.

I have spoken to Ian C about this and he has convinced me that I was
wrong to object to deprecating root= and extra=.  So please do what
Ian C says, not what I say.  Sorry.

Thanks,
Ian.

Re: [Qemu-devel] [Xen-devel] [RFC PATCH V3 1/2] xen: pass kernel initrd to qemu [and 1 more messages]

[Chun Yan Liu]

>>> On 7/2/2014 at 11:17 PM, in message
<21428.8829.273127.394928@mariner.uk.xensource.com>, Ian Jackson
<Ian.Jackson@eu.citrix.com> wrote: 
> Ian Campbell writes ("Re: [RFC PATCH V3 1/2] xen: pass kernel initrd to  
> qemu"): 
> > On Mon, 2014-06-23 at 15:22 +0100, Ian Jackson wrote: 
> > > If we are going to do this then I think the kernel, cmdline and 
> > > ramdisk (and bootloader) parameters shoudl be moved into the main part 
> > > of the domain_build_info struct.  This will involve a compatibility 
> > > layer: temporarily (for at least one release) 
> >  
> > I don't think so -- we would need to retain it forever or at least until 
> > some sort of "API break" event. We still guarantee that applications 
> > using the 4.2 API will be supported. 
>  
> Yes.  Sorry, I meant that the compatibility should be retained for 
> some considerable time.  So for now we should honour all the existing 
> config struct members plus also the new cmdline member which should 
> IMO be in the main part of the struct and not inside pv. 

No new member created, it's always 'cmdline' in libxl_domain_build_info.
'root' and 'extra' and new 'cmdline' are only words to config file.

Before, in libxl_domain_build_info, there are only u.pv.kernel|cmdline|ramdisk,
now since both PV and HVM support them, in theory we should move them
to main part, but considering the compatibility issue, I'm not sure which one
is better?
1. add u.hvm.kernel|cmdline|ramdisk and add hvm processing only (as in V2)
2. add u.kernel|cmdline|ramdisk (since now both PV and HVM have these) but
    keep u.pv.kernel|cmdline|ramdisk, add hvm processing, add pv processing
    u.kernel|cmdline|ramdisk too so that new users could use new APIs. (as in V3)

Your suggestions?

- Chunyan



>  
> > > Why are you deprecating root= and extra= ? 
> >  
> > I suggested this. They are suckful interfaces which expose Linux 
> > specifics (e.g. the root= syntax) in our guest cfg files. cmdline is the 
> > generic equivalent. 
>  
> I have spoken to Ian C about this and he has convinced me that I was 
> wrong to object to deprecating root= and extra=.  So please do what 
> Ian C says, not what I say.  Sorry. 
>  
> Thanks, 
> Ian. 
>  
> _______________________________________________ 
> Xen-devel mailing list 
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 
>  
>  

Re: [Qemu-devel] [Xen-devel] [RFC PATCH V3 1/2] xen: pass kernel initrd to qemu [and 1 more messages]

[Ian Campbell]

On Wed, 2014-07-02 at 23:56 -0600, Chun Yan Liu wrote:
> 
> >>> On 7/2/2014 at 11:17 PM, in message
> <21428.8829.273127.394928@mariner.uk.xensource.com>, Ian Jackson
> <Ian.Jackson@eu.citrix.com> wrote: 
> > Ian Campbell writes ("Re: [RFC PATCH V3 1/2] xen: pass kernel initrd to  
> > qemu"): 
> > > On Mon, 2014-06-23 at 15:22 +0100, Ian Jackson wrote: 
> > > > If we are going to do this then I think the kernel, cmdline and 
> > > > ramdisk (and bootloader) parameters shoudl be moved into the main part 
> > > > of the domain_build_info struct.  This will involve a compatibility 
> > > > layer: temporarily (for at least one release) 
> > >  
> > > I don't think so -- we would need to retain it forever or at least until 
> > > some sort of "API break" event. We still guarantee that applications 
> > > using the 4.2 API will be supported. 
> >  
> > Yes.  Sorry, I meant that the compatibility should be retained for 
> > some considerable time.  So for now we should honour all the existing 
> > config struct members plus also the new cmdline member which should 
> > IMO be in the main part of the struct and not inside pv. 
> 
> No new member created, it's always 'cmdline' in libxl_domain_build_info.
> 'root' and 'extra' and new 'cmdline' are only words to config file.
> 
> Before, in libxl_domain_build_info, there are only u.pv.kernel|cmdline|ramdisk,
> now since both PV and HVM support them, in theory we should move them
> to main part, but considering the compatibility issue, I'm not sure which one
> is better?
> 1. add u.hvm.kernel|cmdline|ramdisk and add hvm processing only (as in V2)
> 2. add u.kernel|cmdline|ramdisk (since now both PV and HVM have these) but
>     keep u.pv.kernel|cmdline|ramdisk, add hvm processing, add pv processing
>     u.kernel|cmdline|ramdisk too so that new users could use new APIs. (as in V3)
> 
> Your suggestions?

Something like 2 is the correct thing.

The final b_info struct should have the new fields:
   b_info->{kernel,cmdline,ramdisk}
and these existing ones:
   b_info->u.pv.{kernel,cmdline,ramdisk}

In libxl__domain_build_info_setdefaults you should then do, iff type ==
PV:
   if (!b_info->kernel)
       b_info->kernel = b_info->u.pv.kernel;
   b_info->u.pv.kernel = NULL;

likewise for ramdisk and cmdline.

and then all of the remaining library code should use b_info->kernel
exclusively.

Ian.

[Qemu-devel] [RFC PATCH V3 2/2] qemu: support xen hvm direct kernel boot

[Chunyan Liu]

qemu side patch to support xen HVM direct kernel boot:
if -kernel exists, calls xen_load_linux(), which will read kernel/initrd
and add a linuxboot.bin or multiboot.bin option rom. The
linuxboot.bin/multiboot.bin will load kernel/initrd and jump to execute
kernel directly. It's working when xen uses seabios.

Signed-off-by: Chunyan Liu <cyliu@suse.com>
---
 hw/i386/pc.c           | 22 ++++++++++++++++++++++
 hw/i386/pc_piix.c      |  7 +++++++
 hw/i386/xen/xen_apic.c |  1 +
 include/hw/i386/pc.h   |  5 +++++
 4 files changed, 35 insertions(+)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 3e0ecf1..e005136 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1183,6 +1183,28 @@ void pc_acpi_init(const char *default_dsdt)
     }
 }
 
+FWCfgState *xen_load_linux(const char *kernel_filename,
+                           const char *kernel_cmdline,
+                           const char *initrd_filename,
+                           ram_addr_t below_4g_mem_size,
+                           PcGuestInfo *guest_info)
+{
+    int i;
+    FWCfgState *fw_cfg;
+
+    assert(kernel_filename != NULL);
+
+    fw_cfg = fw_cfg_init(BIOS_CFG_IOPORT, BIOS_CFG_IOPORT + 1, 0, 0);
+    rom_set_fw(fw_cfg);
+
+    load_linux(fw_cfg, kernel_filename, initrd_filename, kernel_cmdline, below_4g_mem_size);
+    for (i = 0; i < nb_option_roms; i++) {
+        rom_add_option(option_rom[i].name, option_rom[i].bootindex);
+    }
+    guest_info->fw_cfg = fw_cfg;
+    return fw_cfg;
+}
+
 FWCfgState *pc_memory_init(MemoryRegion *system_memory,
                            const char *kernel_filename,
                            const char *kernel_cmdline,
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index a48e263..b737868 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -158,6 +158,13 @@ static void pc_init1(MachineState *machine,
                        machine->initrd_filename,
                        below_4g_mem_size, above_4g_mem_size,
                        rom_memory, &ram_memory, guest_info);
+    } else if (machine->kernel_filename != NULL) {
+        /* For xen HVM direct kernel boot, load linux here */
+        fw_cfg = xen_load_linux(machine->kernel_filename,
+                                machine->kernel_cmdline,
+                                machine->initrd_filename,
+                                below_4g_mem_size,
+                                guest_info);
     }
 
     gsi_state = g_malloc0(sizeof(*gsi_state));
diff --git a/hw/i386/xen/xen_apic.c b/hw/i386/xen/xen_apic.c
index 63bb7f7..f5acd6a 100644
--- a/hw/i386/xen/xen_apic.c
+++ b/hw/i386/xen/xen_apic.c
@@ -40,6 +40,7 @@ static void xen_apic_realize(DeviceState *dev, Error **errp)
 {
     APICCommonState *s = APIC_COMMON(dev);
 
+    s->vapic_control = 0;
     memory_region_init_io(&s->io_memory, OBJECT(s), &xen_apic_io_ops, s,
                           "xen-apic-msi", APIC_SPACE_SIZE);
 
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index ca7a0bd..171a597 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -134,6 +134,11 @@ PcGuestInfo *pc_guest_info_init(ram_addr_t below_4g_mem_size,
 void pc_pci_as_mapping_init(Object *owner, MemoryRegion *system_memory,
                             MemoryRegion *pci_address_space);
 
+FWCfgState *xen_load_linux(const char *kernel_filename,
+                           const char *kernel_cmdline,
+                           const char *initrd_filename,
+                           ram_addr_t below_4g_mem_size,
+                           PcGuestInfo *guest_info);
 FWCfgState *pc_memory_init(MemoryRegion *system_memory,
                            const char *kernel_filename,
                            const char *kernel_cmdline,
-- 
1.8.4.5

Re: [Qemu-devel] [RFC PATCH V3 2/2] qemu: support xen hvm direct kernel boot

[Stefano Stabellini]

On Fri, 20 Jun 2014, Chunyan Liu wrote:
> qemu side patch to support xen HVM direct kernel boot:
> if -kernel exists, calls xen_load_linux(), which will read kernel/initrd
> and add a linuxboot.bin or multiboot.bin option rom. The
> linuxboot.bin/multiboot.bin will load kernel/initrd and jump to execute
> kernel directly. It's working when xen uses seabios.
> 
> Signed-off-by: Chunyan Liu <cyliu@suse.com>
> ---
>  hw/i386/pc.c           | 22 ++++++++++++++++++++++
>  hw/i386/pc_piix.c      |  7 +++++++
>  hw/i386/xen/xen_apic.c |  1 +
>  include/hw/i386/pc.h   |  5 +++++
>  4 files changed, 35 insertions(+)
> 
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 3e0ecf1..e005136 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -1183,6 +1183,28 @@ void pc_acpi_init(const char *default_dsdt)
>      }
>  }
>  
> +FWCfgState *xen_load_linux(const char *kernel_filename,
> +                           const char *kernel_cmdline,
> +                           const char *initrd_filename,
> +                           ram_addr_t below_4g_mem_size,
> +                           PcGuestInfo *guest_info)
> +{
> +    int i;
> +    FWCfgState *fw_cfg;
> +
> +    assert(kernel_filename != NULL);
> +
> +    fw_cfg = fw_cfg_init(BIOS_CFG_IOPORT, BIOS_CFG_IOPORT + 1, 0, 0);

Is it actually OK to initialize just BIOS_CFG_IOPORT and avoid
everything else currently done in bochs_bios_init?
Would it make sense to simply call bochs_bios_init?


> +    rom_set_fw(fw_cfg);
> +
> +    load_linux(fw_cfg, kernel_filename, initrd_filename, kernel_cmdline, below_4g_mem_size);
> +    for (i = 0; i < nb_option_roms; i++) {
> +        rom_add_option(option_rom[i].name, option_rom[i].bootindex);
> +    }

Wouldn't this have the unintended consequence of possibly loading other
option_roms into the guest memory?


> +    guest_info->fw_cfg = fw_cfg;
> +    return fw_cfg;
> +}
> +
>  FWCfgState *pc_memory_init(MemoryRegion *system_memory,
>                             const char *kernel_filename,
>                             const char *kernel_cmdline,
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index a48e263..b737868 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -158,6 +158,13 @@ static void pc_init1(MachineState *machine,
>                         machine->initrd_filename,
>                         below_4g_mem_size, above_4g_mem_size,
>                         rom_memory, &ram_memory, guest_info);
> +    } else if (machine->kernel_filename != NULL) {
> +        /* For xen HVM direct kernel boot, load linux here */
> +        fw_cfg = xen_load_linux(machine->kernel_filename,
> +                                machine->kernel_cmdline,
> +                                machine->initrd_filename,
> +                                below_4g_mem_size,
> +                                guest_info);
>      }
>  
>      gsi_state = g_malloc0(sizeof(*gsi_state));
> diff --git a/hw/i386/xen/xen_apic.c b/hw/i386/xen/xen_apic.c
> index 63bb7f7..f5acd6a 100644
> --- a/hw/i386/xen/xen_apic.c
> +++ b/hw/i386/xen/xen_apic.c
> @@ -40,6 +40,7 @@ static void xen_apic_realize(DeviceState *dev, Error **errp)
>  {
>      APICCommonState *s = APIC_COMMON(dev);
>  
> +    s->vapic_control = 0;
>      memory_region_init_io(&s->io_memory, OBJECT(s), &xen_apic_io_ops, s,
>                            "xen-apic-msi", APIC_SPACE_SIZE);

Why this change? It is not mentioned in the commit message.


> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index ca7a0bd..171a597 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -134,6 +134,11 @@ PcGuestInfo *pc_guest_info_init(ram_addr_t below_4g_mem_size,
>  void pc_pci_as_mapping_init(Object *owner, MemoryRegion *system_memory,
>                              MemoryRegion *pci_address_space);
>  
> +FWCfgState *xen_load_linux(const char *kernel_filename,
> +                           const char *kernel_cmdline,
> +                           const char *initrd_filename,
> +                           ram_addr_t below_4g_mem_size,
> +                           PcGuestInfo *guest_info);
>  FWCfgState *pc_memory_init(MemoryRegion *system_memory,
>                             const char *kernel_filename,
>                             const char *kernel_cmdline,
> -- 
> 1.8.4.5
> 

Re: [Qemu-devel] [Xen-devel] [RFC PATCH V3 2/2] qemu: support xen hvm direct kernel boot

[Chun Yan Liu]

>>> On 6/20/2014 at 08:08 PM, in message
<alpine.DEB.2.02.1406201300410.6594@kaball.uk.xensource.com>, Stefano
Stabellini <stefano.stabellini@eu.citrix.com> wrote: 
> On Fri, 20 Jun 2014, Chunyan Liu wrote: 
> > qemu side patch to support xen HVM direct kernel boot: 
> > if -kernel exists, calls xen_load_linux(), which will read kernel/initrd 
> > and add a linuxboot.bin or multiboot.bin option rom. The 
> > linuxboot.bin/multiboot.bin will load kernel/initrd and jump to execute 
> > kernel directly. It's working when xen uses seabios. 
> >  
> > Signed-off-by: Chunyan Liu <cyliu@suse.com> 
> > --- 
> >  hw/i386/pc.c           | 22 ++++++++++++++++++++++ 
> >  hw/i386/pc_piix.c      |  7 +++++++ 
> >  hw/i386/xen/xen_apic.c |  1 + 
> >  include/hw/i386/pc.h   |  5 +++++ 
> >  4 files changed, 35 insertions(+) 
> >  
> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c 
> > index 3e0ecf1..e005136 100644 
> > --- a/hw/i386/pc.c 
> > +++ b/hw/i386/pc.c 
> > @@ -1183,6 +1183,28 @@ void pc_acpi_init(const char *default_dsdt) 
> >      } 
> >  } 
> >   
> > +FWCfgState *xen_load_linux(const char *kernel_filename, 
> > +                           const char *kernel_cmdline, 
> > +                           const char *initrd_filename, 
> > +                           ram_addr_t below_4g_mem_size, 
> > +                           PcGuestInfo *guest_info) 
> > +{ 
> > +    int i; 
> > +    FWCfgState *fw_cfg; 
> > + 
> > +    assert(kernel_filename != NULL); 
> > + 
> > +    fw_cfg = fw_cfg_init(BIOS_CFG_IOPORT, BIOS_CFG_IOPORT + 1, 0, 0); 
>  
> Is it actually OK to initialize just BIOS_CFG_IOPORT and avoid 
> everything else currently done in bochs_bios_init? 
> Would it make sense to simply call bochs_bios_init? 
>  
>  
> > +    rom_set_fw(fw_cfg); 
> > + 
> > +    load_linux(fw_cfg, kernel_filename, initrd_filename, kernel_cmdline,  
> below_4g_mem_size); 
> > +    for (i = 0; i < nb_option_roms; i++) { 
> > +        rom_add_option(option_rom[i].name, option_rom[i].bootindex); 
> > +    } 
>  
> Wouldn't this have the unintended consequence of possibly loading other 
> option_roms into the guest memory? 

For xen, no.

Before this patch, indeed there is another option_rom "kvmvapic" in the list,
but since the option_rom list is never loaded in xen case, that won't harm. But
as expected, I think in xen case, it should not be in option_rom list at all, since
we won't expect to load it. In v1, I tried to check the option_rom name to
bypass it and load multiboot.bin/linuxboot.bin only.

In comments, Paolo Bonzini suggests a better way, that is to add following line
in xen_apic_realize():
+ s->vapic_control = 0;
In this way, "kvmvapic" won't be added to the option_rom list. I think that
should be the normal way for xen.

So, since V2, I updated in this way.
http://lists.gnu.org/archive/html/qemu-devel/2014-06/msg00704.html

>  
>  
> > +    guest_info->fw_cfg = fw_cfg; 
> > +    return fw_cfg; 
> > +} 
> > + 
> >  FWCfgState *pc_memory_init(MemoryRegion *system_memory, 
> >                             const char *kernel_filename, 
> >                             const char *kernel_cmdline, 
> > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c 
> > index a48e263..b737868 100644 
> > --- a/hw/i386/pc_piix.c 
> > +++ b/hw/i386/pc_piix.c 
> > @@ -158,6 +158,13 @@ static void pc_init1(MachineState *machine, 
> >                         machine->initrd_filename, 
> >                         below_4g_mem_size, above_4g_mem_size, 
> >                         rom_memory, &ram_memory, guest_info); 
> > +    } else if (machine->kernel_filename != NULL) { 
> > +        /* For xen HVM direct kernel boot, load linux here */ 
> > +        fw_cfg = xen_load_linux(machine->kernel_filename, 
> > +                                machine->kernel_cmdline, 
> > +                                machine->initrd_filename, 
> > +                                below_4g_mem_size, 
> > +                                guest_info); 
> >      } 
> >   
> >      gsi_state = g_malloc0(sizeof(*gsi_state)); 
> > diff --git a/hw/i386/xen/xen_apic.c b/hw/i386/xen/xen_apic.c 
> > index 63bb7f7..f5acd6a 100644 
> > --- a/hw/i386/xen/xen_apic.c 
> > +++ b/hw/i386/xen/xen_apic.c 
> > @@ -40,6 +40,7 @@ static void xen_apic_realize(DeviceState *dev, Error  
> **errp) 
> >  { 
> >      APICCommonState *s = APIC_COMMON(dev); 
> >   
> > +    s->vapic_control = 0; 
> >      memory_region_init_io(&s->io_memory, OBJECT(s), &xen_apic_io_ops, s, 
> >                            "xen-apic-msi", APIC_SPACE_SIZE); 
>  
> Why this change? It is not mentioned in the commit message. 
>  
>  
> > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h 
> > index ca7a0bd..171a597 100644 
> > --- a/include/hw/i386/pc.h 
> > +++ b/include/hw/i386/pc.h 
> > @@ -134,6 +134,11 @@ PcGuestInfo *pc_guest_info_init(ram_addr_t  
> below_4g_mem_size, 
> >  void pc_pci_as_mapping_init(Object *owner, MemoryRegion *system_memory, 
> >                              MemoryRegion *pci_address_space); 
> >   
> > +FWCfgState *xen_load_linux(const char *kernel_filename, 
> > +                           const char *kernel_cmdline, 
> > +                           const char *initrd_filename, 
> > +                           ram_addr_t below_4g_mem_size, 
> > +                           PcGuestInfo *guest_info); 
> >  FWCfgState *pc_memory_init(MemoryRegion *system_memory, 
> >                             const char *kernel_filename, 
> >                             const char *kernel_cmdline, 
> > --  
> > 1.8.4.5 
> >  
>  
> _______________________________________________ 
> Xen-devel mailing list 
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 
>  
>  

Re: [Qemu-devel] [Xen-devel] [RFC PATCH V3 2/2] qemu: support xen hvm direct kernel boot

[Stefano Stabellini]

On Sun, 22 Jun 2014, Chun Yan Liu wrote:
> >>> On 6/20/2014 at 08:08 PM, in message
> <alpine.DEB.2.02.1406201300410.6594@kaball.uk.xensource.com>, Stefano
> Stabellini <stefano.stabellini@eu.citrix.com> wrote: 
> > On Fri, 20 Jun 2014, Chunyan Liu wrote: 
> > > qemu side patch to support xen HVM direct kernel boot: 
> > > if -kernel exists, calls xen_load_linux(), which will read kernel/initrd 
> > > and add a linuxboot.bin or multiboot.bin option rom. The 
> > > linuxboot.bin/multiboot.bin will load kernel/initrd and jump to execute 
> > > kernel directly. It's working when xen uses seabios. 
> > >  
> > > Signed-off-by: Chunyan Liu <cyliu@suse.com> 
> > > --- 
> > >  hw/i386/pc.c           | 22 ++++++++++++++++++++++ 
> > >  hw/i386/pc_piix.c      |  7 +++++++ 
> > >  hw/i386/xen/xen_apic.c |  1 + 
> > >  include/hw/i386/pc.h   |  5 +++++ 
> > >  4 files changed, 35 insertions(+) 
> > >  
> > > diff --git a/hw/i386/pc.c b/hw/i386/pc.c 
> > > index 3e0ecf1..e005136 100644 
> > > --- a/hw/i386/pc.c 
> > > +++ b/hw/i386/pc.c 
> > > @@ -1183,6 +1183,28 @@ void pc_acpi_init(const char *default_dsdt) 
> > >      } 
> > >  } 
> > >   
> > > +FWCfgState *xen_load_linux(const char *kernel_filename, 
> > > +                           const char *kernel_cmdline, 
> > > +                           const char *initrd_filename, 
> > > +                           ram_addr_t below_4g_mem_size, 
> > > +                           PcGuestInfo *guest_info) 
> > > +{ 
> > > +    int i; 
> > > +    FWCfgState *fw_cfg; 
> > > + 
> > > +    assert(kernel_filename != NULL); 
> > > + 
> > > +    fw_cfg = fw_cfg_init(BIOS_CFG_IOPORT, BIOS_CFG_IOPORT + 1, 0, 0); 
> >  
> > Is it actually OK to initialize just BIOS_CFG_IOPORT and avoid 
> > everything else currently done in bochs_bios_init? 
> > Would it make sense to simply call bochs_bios_init? 
> >  
> >  
> > > +    rom_set_fw(fw_cfg); 
> > > + 
> > > +    load_linux(fw_cfg, kernel_filename, initrd_filename, kernel_cmdline,  
> > below_4g_mem_size); 
> > > +    for (i = 0; i < nb_option_roms; i++) { 
> > > +        rom_add_option(option_rom[i].name, option_rom[i].bootindex); 
> > > +    } 
> >  
> > Wouldn't this have the unintended consequence of possibly loading other 
> > option_roms into the guest memory? 
> 
> For xen, no.
> 
> Before this patch, indeed there is another option_rom "kvmvapic" in the list,
> but since the option_rom list is never loaded in xen case, that won't harm. But
> as expected, I think in xen case, it should not be in option_rom list at all, since
> we won't expect to load it. In v1, I tried to check the option_rom name to
> bypass it and load multiboot.bin/linuxboot.bin only.
> 
> In comments, Paolo Bonzini suggests a better way, that is to add following line
> in xen_apic_realize():
> + s->vapic_control = 0;
> In this way, "kvmvapic" won't be added to the option_rom list. I think that
> should be the normal way for xen.
> 
> So, since V2, I updated in this way.
> http://lists.gnu.org/archive/html/qemu-devel/2014-06/msg00704.html

I see. Paolo's suggestion is a good one.

I would add an assert here to ensure that there is only one option
rom named "linuxboot.bin", so that we can easily spot if something in
the future breaks our assumptions.


> >  
> >  
> > > +    guest_info->fw_cfg = fw_cfg; 
> > > +    return fw_cfg; 
> > > +} 
> > > + 
> > >  FWCfgState *pc_memory_init(MemoryRegion *system_memory, 
> > >                             const char *kernel_filename, 
> > >                             const char *kernel_cmdline, 
> > > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c 
> > > index a48e263..b737868 100644 
> > > --- a/hw/i386/pc_piix.c 
> > > +++ b/hw/i386/pc_piix.c 
> > > @@ -158,6 +158,13 @@ static void pc_init1(MachineState *machine, 
> > >                         machine->initrd_filename, 
> > >                         below_4g_mem_size, above_4g_mem_size, 
> > >                         rom_memory, &ram_memory, guest_info); 
> > > +    } else if (machine->kernel_filename != NULL) { 
> > > +        /* For xen HVM direct kernel boot, load linux here */ 
> > > +        fw_cfg = xen_load_linux(machine->kernel_filename, 
> > > +                                machine->kernel_cmdline, 
> > > +                                machine->initrd_filename, 
> > > +                                below_4g_mem_size, 
> > > +                                guest_info); 
> > >      } 
> > >   
> > >      gsi_state = g_malloc0(sizeof(*gsi_state)); 
> > > diff --git a/hw/i386/xen/xen_apic.c b/hw/i386/xen/xen_apic.c 
> > > index 63bb7f7..f5acd6a 100644 
> > > --- a/hw/i386/xen/xen_apic.c 
> > > +++ b/hw/i386/xen/xen_apic.c 
> > > @@ -40,6 +40,7 @@ static void xen_apic_realize(DeviceState *dev, Error  
> > **errp) 
> > >  { 
> > >      APICCommonState *s = APIC_COMMON(dev); 
> > >   
> > > +    s->vapic_control = 0; 
> > >      memory_region_init_io(&s->io_memory, OBJECT(s), &xen_apic_io_ops, s, 
> > >                            "xen-apic-msi", APIC_SPACE_SIZE); 
> >  
> > Why this change? It is not mentioned in the commit message. 
> >  
> >  
> > > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h 
> > > index ca7a0bd..171a597 100644 
> > > --- a/include/hw/i386/pc.h 
> > > +++ b/include/hw/i386/pc.h 
> > > @@ -134,6 +134,11 @@ PcGuestInfo *pc_guest_info_init(ram_addr_t  
> > below_4g_mem_size, 
> > >  void pc_pci_as_mapping_init(Object *owner, MemoryRegion *system_memory, 
> > >                              MemoryRegion *pci_address_space); 
> > >   
> > > +FWCfgState *xen_load_linux(const char *kernel_filename, 
> > > +                           const char *kernel_cmdline, 
> > > +                           const char *initrd_filename, 
> > > +                           ram_addr_t below_4g_mem_size, 
> > > +                           PcGuestInfo *guest_info); 
> > >  FWCfgState *pc_memory_init(MemoryRegion *system_memory, 
> > >                             const char *kernel_filename, 
> > >                             const char *kernel_cmdline, 
> > > --  
> > > 1.8.4.5 
> > >  
> >  
> > _______________________________________________ 
> > Xen-devel mailing list 
> > Xen-devel@lists.xen.org 
> > http://lists.xen.org/xen-devel 
> >  
> >  
> 

Re: [Qemu-devel] [Xen-devel] [RFC PATCH V3 2/2] qemu: support xen hvm direct kernel boot

[Chun Yan Liu]

>>> On 6/23/2014 at 06:14 PM, in message
<alpine.DEB.2.02.1406231110050.19982@kaball.uk.xensource.com>, Stefano
Stabellini <stefano.stabellini@eu.citrix.com> wrote: 
> On Sun, 22 Jun 2014, Chun Yan Liu wrote: 
> > >>> On 6/20/2014 at 08:08 PM, in message 
> > <alpine.DEB.2.02.1406201300410.6594@kaball.uk.xensource.com>, Stefano 
> > Stabellini <stefano.stabellini@eu.citrix.com> wrote:  
> > > On Fri, 20 Jun 2014, Chunyan Liu wrote:  
> > > > qemu side patch to support xen HVM direct kernel boot:  
> > > > if -kernel exists, calls xen_load_linux(), which will read kernel/initrd  
> > > > and add a linuxboot.bin or multiboot.bin option rom. The  
> > > > linuxboot.bin/multiboot.bin will load kernel/initrd and jump to execute  
> > > > kernel directly. It's working when xen uses seabios.  
> > > >   
> > > > Signed-off-by: Chunyan Liu <cyliu@suse.com>  
> > > > ---  
> > > >  hw/i386/pc.c           | 22 ++++++++++++++++++++++  
> > > >  hw/i386/pc_piix.c      |  7 +++++++  
> > > >  hw/i386/xen/xen_apic.c |  1 +  
> > > >  include/hw/i386/pc.h   |  5 +++++  
> > > >  4 files changed, 35 insertions(+)  
> > > >   
> > > > diff --git a/hw/i386/pc.c b/hw/i386/pc.c  
> > > > index 3e0ecf1..e005136 100644  
> > > > --- a/hw/i386/pc.c  
> > > > +++ b/hw/i386/pc.c  
> > > > @@ -1183,6 +1183,28 @@ void pc_acpi_init(const char *default_dsdt)  
> > > >      }  
> > > >  }  
> > > >    
> > > > +FWCfgState *xen_load_linux(const char *kernel_filename,  
> > > > +                           const char *kernel_cmdline,  
> > > > +                           const char *initrd_filename,  
> > > > +                           ram_addr_t below_4g_mem_size,  
> > > > +                           PcGuestInfo *guest_info)  
> > > > +{  
> > > > +    int i;  
> > > > +    FWCfgState *fw_cfg;  
> > > > +  
> > > > +    assert(kernel_filename != NULL);  
> > > > +  
> > > > +    fw_cfg = fw_cfg_init(BIOS_CFG_IOPORT, BIOS_CFG_IOPORT + 1, 0, 0);  
> > >   
> > > Is it actually OK to initialize just BIOS_CFG_IOPORT and avoid  
> > > everything else currently done in bochs_bios_init?  
> > > Would it make sense to simply call bochs_bios_init?  
> > >   
> > >   
> > > > +    rom_set_fw(fw_cfg);  
> > > > +  
> > > > +    load_linux(fw_cfg, kernel_filename, initrd_filename, kernel_cmdline,  
>   
> > > below_4g_mem_size);  
> > > > +    for (i = 0; i < nb_option_roms; i++) {  
> > > > +        rom_add_option(option_rom[i].name, option_rom[i].bootindex);  
> > > > +    }  
> > >   
> > > Wouldn't this have the unintended consequence of possibly loading other  
> > > option_roms into the guest memory?  
> >  
> > For xen, no. 
> >  
> > Before this patch, indeed there is another option_rom "kvmvapic" in the  
> list, 
> > but since the option_rom list is never loaded in xen case, that won't harm.  
> But 
> > as expected, I think in xen case, it should not be in option_rom list at  
> all, since 
> > we won't expect to load it. In v1, I tried to check the option_rom name to 
> > bypass it and load multiboot.bin/linuxboot.bin only. 
> >  
> > In comments, Paolo Bonzini suggests a better way, that is to add following  
> line 
> > in xen_apic_realize(): 
> > + s->vapic_control = 0; 
> > In this way, "kvmvapic" won't be added to the option_rom list. I think that 
> > should be the normal way for xen. 
> >  
> > So, since V2, I updated in this way. 
> > http://lists.gnu.org/archive/html/qemu-devel/2014-06/msg00704.html 
>  
> I see. Paolo's suggestion is a good one. 
>  
> I would add an assert here to ensure that there is only one option 
> rom named "linuxboot.bin", so that we can easily spot if something in 
> the future breaks our assumptions. 

Yes, that's better. Will update. Thanks!

>  
>  
> > >   
> > >   
> > > > +    guest_info->fw_cfg = fw_cfg;  
> > > > +    return fw_cfg;  
> > > > +}  
> > > > +  
> > > >  FWCfgState *pc_memory_init(MemoryRegion *system_memory,  
> > > >                             const char *kernel_filename,  
> > > >                             const char *kernel_cmdline,  
> > > > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c  
> > > > index a48e263..b737868 100644  
> > > > --- a/hw/i386/pc_piix.c  
> > > > +++ b/hw/i386/pc_piix.c  
> > > > @@ -158,6 +158,13 @@ static void pc_init1(MachineState *machine,  
> > > >                         machine->initrd_filename,  
> > > >                         below_4g_mem_size, above_4g_mem_size,  
> > > >                         rom_memory, &ram_memory, guest_info);  
> > > > +    } else if (machine->kernel_filename != NULL) {  
> > > > +        /* For xen HVM direct kernel boot, load linux here */  
> > > > +        fw_cfg = xen_load_linux(machine->kernel_filename,  
> > > > +                                machine->kernel_cmdline,  
> > > > +                                machine->initrd_filename,  
> > > > +                                below_4g_mem_size,  
> > > > +                                guest_info);  
> > > >      }  
> > > >    
> > > >      gsi_state = g_malloc0(sizeof(*gsi_state));  
> > > > diff --git a/hw/i386/xen/xen_apic.c b/hw/i386/xen/xen_apic.c  
> > > > index 63bb7f7..f5acd6a 100644  
> > > > --- a/hw/i386/xen/xen_apic.c  
> > > > +++ b/hw/i386/xen/xen_apic.c  
> > > > @@ -40,6 +40,7 @@ static void xen_apic_realize(DeviceState *dev, Error   
> > > **errp)  
> > > >  {  
> > > >      APICCommonState *s = APIC_COMMON(dev);  
> > > >    
> > > > +    s->vapic_control = 0;  
> > > >      memory_region_init_io(&s->io_memory, OBJECT(s), &xen_apic_io_ops, s,  
> > > >                            "xen-apic-msi", APIC_SPACE_SIZE);  
> > >   
> > > Why this change? It is not mentioned in the commit message.  
> > >   
> > >   
> > > > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h  
> > > > index ca7a0bd..171a597 100644  
> > > > --- a/include/hw/i386/pc.h  
> > > > +++ b/include/hw/i386/pc.h  
> > > > @@ -134,6 +134,11 @@ PcGuestInfo *pc_guest_info_init(ram_addr_t   
> > > below_4g_mem_size,  
> > > >  void pc_pci_as_mapping_init(Object *owner, MemoryRegion *system_memory,  
> > > >                              MemoryRegion *pci_address_space);  
> > > >    
> > > > +FWCfgState *xen_load_linux(const char *kernel_filename,  
> > > > +                           const char *kernel_cmdline,  
> > > > +                           const char *initrd_filename,  
> > > > +                           ram_addr_t below_4g_mem_size,  
> > > > +                           PcGuestInfo *guest_info);  
> > > >  FWCfgState *pc_memory_init(MemoryRegion *system_memory,  
> > > >                             const char *kernel_filename,  
> > > >                             const char *kernel_cmdline,  
> > > > --   
> > > > 1.8.4.5  
> > > >   
> > >   
> > > _______________________________________________  
> > > Xen-devel mailing list  
> > > Xen-devel@lists.xen.org  
> > > http://lists.xen.org/xen-devel  
> > >   
> > >   
> >  
>  
>  

Re: [Qemu-devel] [RFC PATCH V4 1/2] xen: pass kernel initrd to qemu

[Ian Campbell]

On Tue, 2014-07-01 at 15:06 +0800, Chunyan Liu wrote:
> xen side patch to support xen HVM direct kernel boot:
> support 'kernel', 'ramdisk', 'cmdline' (and 'root', 'extra' as well
> which would be deprecated later) in HVM config file, parse config file,
> pass -kernel, -initrd, -append parameters to qemu.
> 
> It's working with qemu-xen when using the default BIOS (seabios).
> 
> [config example]
> kernel="/mnt/vmlinuz-3.0.13-0.27-default"
> ramdisk="/mnt/initrd-3.0.13-0.27-default"
> root="/dev/hda2"
> extra="console=tty0 console=ttyS0"

Is this example complete? I think it will create a PV guest which isn't
what you are trying to demonstrate.

Ian.

Re: [Qemu-devel] [Xen-devel] [RFC PATCH V4 1/2] xen: pass kernel initrd to qemu

[Chun Yan Liu]

>>> On 7/2/2014 at 11:16 PM, in message
<1404314181.8137.7.camel@kazak.uk.xensource.com>, Ian Campbell
<Ian.Campbell@citrix.com> wrote: 
> On Tue, 2014-07-01 at 15:06 +0800, Chunyan Liu wrote: 
> > xen side patch to support xen HVM direct kernel boot: 
> > support 'kernel', 'ramdisk', 'cmdline' (and 'root', 'extra' as well 
> > which would be deprecated later) in HVM config file, parse config file, 
> > pass -kernel, -initrd, -append parameters to qemu. 
> >  
> > It's working with qemu-xen when using the default BIOS (seabios). 
> >  
> > [config example] 
> > kernel="/mnt/vmlinuz-3.0.13-0.27-default" 
> > ramdisk="/mnt/initrd-3.0.13-0.27-default" 
> > root="/dev/hda2" 
> > extra="console=tty0 console=ttyS0" 
>  
> Is this example complete? I think it will create a PV guest which isn't 
> what you are trying to demonstrate. 

This is a HVM example.
For PV guest, it already supports direct kernel boot before this patch, so
use as before. No changes in config file.
I'll update the examples after readding 'cmdline' parameter.

Thank you.
-Chunyan

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

Re: [Qemu-devel] [Xen-devel] [RFC PATCH V4 1/2] xen: pass kernel initrd to qemu

[Ian Campbell]

On Wed, 2014-07-02 at 20:34 -0600, Chun Yan Liu wrote:
> 
> >>> On 7/2/2014 at 11:16 PM, in message
> <1404314181.8137.7.camel@kazak.uk.xensource.com>, Ian Campbell
> <Ian.Campbell@citrix.com> wrote: 
> > On Tue, 2014-07-01 at 15:06 +0800, Chunyan Liu wrote: 
> > > xen side patch to support xen HVM direct kernel boot: 
> > > support 'kernel', 'ramdisk', 'cmdline' (and 'root', 'extra' as well 
> > > which would be deprecated later) in HVM config file, parse config file, 
> > > pass -kernel, -initrd, -append parameters to qemu. 
> > >  
> > > It's working with qemu-xen when using the default BIOS (seabios). 
> > >  
> > > [config example] 
> > > kernel="/mnt/vmlinuz-3.0.13-0.27-default" 
> > > ramdisk="/mnt/initrd-3.0.13-0.27-default" 
> > > root="/dev/hda2" 
> > > extra="console=tty0 console=ttyS0" 
> >  
> > Is this example complete? I think it will create a PV guest which isn't 
> > what you are trying to demonstrate. 
> 
> This is a HVM example.

But none of the parameters given would cause it to be so, would they? I
think if you were to paste exactly that into a cfg file you would end up
with a PV guest.

Specifically it is missing: builder="hvm"

Ian.

[Qemu-devel] [RFC PATCH V4 2/2] qemu: support xen hvm direct kernel boot

[Chunyan Liu]

qemu side patch to support xen HVM direct kernel boot:
if -kernel exists, calls xen_load_linux(), which will read kernel/initrd
and add a linuxboot.bin or multiboot.bin option rom. The
linuxboot.bin/multiboot.bin will load kernel/initrd and jump to execute
kernel directly. It's working when xen uses seabios.

During this work, found the 'kvmvapic' is in option_rom list, it should
not be there in xen case. Set s->vapic_control = 0 in xen_apic_realize()
to handle that.

Signed-off-by: Chunyan Liu <cyliu@suse.com>
---
Changes to v3:
  - add assertion before adding option rom as Stefan suggests

 hw/i386/pc.c           | 25 +++++++++++++++++++++++++
 hw/i386/pc_piix.c      |  7 +++++++
 hw/i386/xen/xen_apic.c |  1 +
 include/hw/i386/pc.h   |  5 +++++
 4 files changed, 38 insertions(+)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 2cf22b1..9e58982 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1190,6 +1190,31 @@ void pc_acpi_init(const char *default_dsdt)
     }
 }
 
+FWCfgState *xen_load_linux(const char *kernel_filename,
+                           const char *kernel_cmdline,
+                           const char *initrd_filename,
+                           ram_addr_t below_4g_mem_size,
+                           PcGuestInfo *guest_info)
+{
+    int i;
+    FWCfgState *fw_cfg;
+
+    assert(kernel_filename != NULL);
+
+    fw_cfg = fw_cfg_init(BIOS_CFG_IOPORT, BIOS_CFG_IOPORT + 1, 0, 0);
+    rom_set_fw(fw_cfg);
+
+    load_linux(fw_cfg, kernel_filename, initrd_filename,
+               kernel_cmdline, below_4g_mem_size);
+    for (i = 0; i < nb_option_roms; i++) {
+        assert(!strcmp(option_rom[i].name, "linuxboot.bin") ||
+               !strcmp(option_rom[i].name, "multiboot.bin"));
+        rom_add_option(option_rom[i].name, option_rom[i].bootindex);
+    }
+    guest_info->fw_cfg = fw_cfg;
+    return fw_cfg;
+}
+
 FWCfgState *pc_memory_init(MachineState *machine,
                            MemoryRegion *system_memory,
                            ram_addr_t below_4g_mem_size,
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 2dccb34..63e2198 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -180,6 +180,13 @@ static void pc_init1(MachineState *machine,
         fw_cfg = pc_memory_init(machine, system_memory,
                                 below_4g_mem_size, above_4g_mem_size,
                                 rom_memory, &ram_memory, guest_info);
+    } else if (machine->kernel_filename != NULL) {
+        /* For xen HVM direct kernel boot, load linux here */
+        fw_cfg = xen_load_linux(machine->kernel_filename,
+                                machine->kernel_cmdline,
+                                machine->initrd_filename,
+                                below_4g_mem_size,
+                                guest_info);
     }
 
     gsi_state = g_malloc0(sizeof(*gsi_state));
diff --git a/hw/i386/xen/xen_apic.c b/hw/i386/xen/xen_apic.c
index 63bb7f7..f5acd6a 100644
--- a/hw/i386/xen/xen_apic.c
+++ b/hw/i386/xen/xen_apic.c
@@ -40,6 +40,7 @@ static void xen_apic_realize(DeviceState *dev, Error **errp)
 {
     APICCommonState *s = APIC_COMMON(dev);
 
+    s->vapic_control = 0;
     memory_region_init_io(&s->io_memory, OBJECT(s), &xen_apic_io_ops, s,
                           "xen-apic-msi", APIC_SPACE_SIZE);
 
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 1c0c382..b47aaa9 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -187,6 +187,11 @@ PcGuestInfo *pc_guest_info_init(ram_addr_t below_4g_mem_size,
 void pc_pci_as_mapping_init(Object *owner, MemoryRegion *system_memory,
                             MemoryRegion *pci_address_space);
 
+FWCfgState *xen_load_linux(const char *kernel_filename,
+                           const char *kernel_cmdline,
+                           const char *initrd_filename,
+                           ram_addr_t below_4g_mem_size,
+                           PcGuestInfo *guest_info);
 FWCfgState *pc_memory_init(MachineState *machine,
                            MemoryRegion *system_memory,
                            ram_addr_t below_4g_mem_size,
-- 
1.8.4.5

Re: [Qemu-devel] [RFC PATCH V4 2/2] qemu: support xen hvm direct kernel boot

[Stefano Stabellini]

On Tue, 1 Jul 2014, Chunyan Liu wrote:
> qemu side patch to support xen HVM direct kernel boot:
> if -kernel exists, calls xen_load_linux(), which will read kernel/initrd
> and add a linuxboot.bin or multiboot.bin option rom. The
> linuxboot.bin/multiboot.bin will load kernel/initrd and jump to execute
> kernel directly. It's working when xen uses seabios.
> 
> During this work, found the 'kvmvapic' is in option_rom list, it should
> not be there in xen case. Set s->vapic_control = 0 in xen_apic_realize()
> to handle that.
> 
> Signed-off-by: Chunyan Liu <cyliu@suse.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Michael, Paolo, are you happy with this patch?
If so, I am going to add it to my queue, unless you want to take it?


> Changes to v3:
>   - add assertion before adding option rom as Stefan suggests
> 
>  hw/i386/pc.c           | 25 +++++++++++++++++++++++++
>  hw/i386/pc_piix.c      |  7 +++++++
>  hw/i386/xen/xen_apic.c |  1 +
>  include/hw/i386/pc.h   |  5 +++++
>  4 files changed, 38 insertions(+)
> 
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 2cf22b1..9e58982 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -1190,6 +1190,31 @@ void pc_acpi_init(const char *default_dsdt)
>      }
>  }
>  
> +FWCfgState *xen_load_linux(const char *kernel_filename,
> +                           const char *kernel_cmdline,
> +                           const char *initrd_filename,
> +                           ram_addr_t below_4g_mem_size,
> +                           PcGuestInfo *guest_info)
> +{
> +    int i;
> +    FWCfgState *fw_cfg;
> +
> +    assert(kernel_filename != NULL);
> +
> +    fw_cfg = fw_cfg_init(BIOS_CFG_IOPORT, BIOS_CFG_IOPORT + 1, 0, 0);
> +    rom_set_fw(fw_cfg);
> +
> +    load_linux(fw_cfg, kernel_filename, initrd_filename,
> +               kernel_cmdline, below_4g_mem_size);
> +    for (i = 0; i < nb_option_roms; i++) {
> +        assert(!strcmp(option_rom[i].name, "linuxboot.bin") ||
> +               !strcmp(option_rom[i].name, "multiboot.bin"));
> +        rom_add_option(option_rom[i].name, option_rom[i].bootindex);
> +    }
> +    guest_info->fw_cfg = fw_cfg;
> +    return fw_cfg;
> +}
> +
>  FWCfgState *pc_memory_init(MachineState *machine,
>                             MemoryRegion *system_memory,
>                             ram_addr_t below_4g_mem_size,
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 2dccb34..63e2198 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -180,6 +180,13 @@ static void pc_init1(MachineState *machine,
>          fw_cfg = pc_memory_init(machine, system_memory,
>                                  below_4g_mem_size, above_4g_mem_size,
>                                  rom_memory, &ram_memory, guest_info);
> +    } else if (machine->kernel_filename != NULL) {
> +        /* For xen HVM direct kernel boot, load linux here */
> +        fw_cfg = xen_load_linux(machine->kernel_filename,
> +                                machine->kernel_cmdline,
> +                                machine->initrd_filename,
> +                                below_4g_mem_size,
> +                                guest_info);
>      }
>  
>      gsi_state = g_malloc0(sizeof(*gsi_state));
> diff --git a/hw/i386/xen/xen_apic.c b/hw/i386/xen/xen_apic.c
> index 63bb7f7..f5acd6a 100644
> --- a/hw/i386/xen/xen_apic.c
> +++ b/hw/i386/xen/xen_apic.c
> @@ -40,6 +40,7 @@ static void xen_apic_realize(DeviceState *dev, Error **errp)
>  {
>      APICCommonState *s = APIC_COMMON(dev);
>  
> +    s->vapic_control = 0;
>      memory_region_init_io(&s->io_memory, OBJECT(s), &xen_apic_io_ops, s,
>                            "xen-apic-msi", APIC_SPACE_SIZE);
>  
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index 1c0c382..b47aaa9 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -187,6 +187,11 @@ PcGuestInfo *pc_guest_info_init(ram_addr_t below_4g_mem_size,
>  void pc_pci_as_mapping_init(Object *owner, MemoryRegion *system_memory,
>                              MemoryRegion *pci_address_space);
>  
> +FWCfgState *xen_load_linux(const char *kernel_filename,
> +                           const char *kernel_cmdline,
> +                           const char *initrd_filename,
> +                           ram_addr_t below_4g_mem_size,
> +                           PcGuestInfo *guest_info);
>  FWCfgState *pc_memory_init(MachineState *machine,
>                             MemoryRegion *system_memory,
>                             ram_addr_t below_4g_mem_size,
> -- 
> 1.8.4.5
> 

Re: [Qemu-devel] [RFC PATCH V4 2/2] qemu: support xen hvm direct kernel boot

[Michael S. Tsirkin]

On Wed, Jul 02, 2014 at 03:18:56PM +0100, Stefano Stabellini wrote:
> On Tue, 1 Jul 2014, Chunyan Liu wrote:
> > qemu side patch to support xen HVM direct kernel boot:
> > if -kernel exists, calls xen_load_linux(), which will read kernel/initrd
> > and add a linuxboot.bin or multiboot.bin option rom. The
> > linuxboot.bin/multiboot.bin will load kernel/initrd and jump to execute
> > kernel directly. It's working when xen uses seabios.
> > 
> > During this work, found the 'kvmvapic' is in option_rom list, it should
> > not be there in xen case. Set s->vapic_control = 0 in xen_apic_realize()
> > to handle that.

I would make this one a separate patch, it's mixing
bugfixes with features.
But up to you.


> > Signed-off-by: Chunyan Liu <cyliu@suse.com>
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Michael, Paolo, are you happy with this patch?
> If so, I am going to add it to my queue, unless you want to take it?

Pls go ahead.

Acked-by: Michael S. Tsirkin <mst@redhat.com>



> 
> > Changes to v3:
> >   - add assertion before adding option rom as Stefan suggests
> > 
> >  hw/i386/pc.c           | 25 +++++++++++++++++++++++++
> >  hw/i386/pc_piix.c      |  7 +++++++
> >  hw/i386/xen/xen_apic.c |  1 +
> >  include/hw/i386/pc.h   |  5 +++++
> >  4 files changed, 38 insertions(+)
> > 
> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > index 2cf22b1..9e58982 100644
> > --- a/hw/i386/pc.c
> > +++ b/hw/i386/pc.c
> > @@ -1190,6 +1190,31 @@ void pc_acpi_init(const char *default_dsdt)
> >      }
> >  }
> >  
> > +FWCfgState *xen_load_linux(const char *kernel_filename,
> > +                           const char *kernel_cmdline,
> > +                           const char *initrd_filename,
> > +                           ram_addr_t below_4g_mem_size,
> > +                           PcGuestInfo *guest_info)
> > +{
> > +    int i;
> > +    FWCfgState *fw_cfg;
> > +
> > +    assert(kernel_filename != NULL);
> > +
> > +    fw_cfg = fw_cfg_init(BIOS_CFG_IOPORT, BIOS_CFG_IOPORT + 1, 0, 0);
> > +    rom_set_fw(fw_cfg);
> > +
> > +    load_linux(fw_cfg, kernel_filename, initrd_filename,
> > +               kernel_cmdline, below_4g_mem_size);
> > +    for (i = 0; i < nb_option_roms; i++) {
> > +        assert(!strcmp(option_rom[i].name, "linuxboot.bin") ||
> > +               !strcmp(option_rom[i].name, "multiboot.bin"));
> > +        rom_add_option(option_rom[i].name, option_rom[i].bootindex);
> > +    }
> > +    guest_info->fw_cfg = fw_cfg;
> > +    return fw_cfg;
> > +}
> > +
> >  FWCfgState *pc_memory_init(MachineState *machine,
> >                             MemoryRegion *system_memory,
> >                             ram_addr_t below_4g_mem_size,
> > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> > index 2dccb34..63e2198 100644
> > --- a/hw/i386/pc_piix.c
> > +++ b/hw/i386/pc_piix.c
> > @@ -180,6 +180,13 @@ static void pc_init1(MachineState *machine,
> >          fw_cfg = pc_memory_init(machine, system_memory,
> >                                  below_4g_mem_size, above_4g_mem_size,
> >                                  rom_memory, &ram_memory, guest_info);
> > +    } else if (machine->kernel_filename != NULL) {
> > +        /* For xen HVM direct kernel boot, load linux here */
> > +        fw_cfg = xen_load_linux(machine->kernel_filename,
> > +                                machine->kernel_cmdline,
> > +                                machine->initrd_filename,
> > +                                below_4g_mem_size,
> > +                                guest_info);
> >      }
> >  
> >      gsi_state = g_malloc0(sizeof(*gsi_state));
> > diff --git a/hw/i386/xen/xen_apic.c b/hw/i386/xen/xen_apic.c
> > index 63bb7f7..f5acd6a 100644
> > --- a/hw/i386/xen/xen_apic.c
> > +++ b/hw/i386/xen/xen_apic.c
> > @@ -40,6 +40,7 @@ static void xen_apic_realize(DeviceState *dev, Error **errp)
> >  {
> >      APICCommonState *s = APIC_COMMON(dev);
> >  
> > +    s->vapic_control = 0;
> >      memory_region_init_io(&s->io_memory, OBJECT(s), &xen_apic_io_ops, s,
> >                            "xen-apic-msi", APIC_SPACE_SIZE);
> >  
> > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> > index 1c0c382..b47aaa9 100644
> > --- a/include/hw/i386/pc.h
> > +++ b/include/hw/i386/pc.h
> > @@ -187,6 +187,11 @@ PcGuestInfo *pc_guest_info_init(ram_addr_t below_4g_mem_size,
> >  void pc_pci_as_mapping_init(Object *owner, MemoryRegion *system_memory,
> >                              MemoryRegion *pci_address_space);
> >  
> > +FWCfgState *xen_load_linux(const char *kernel_filename,
> > +                           const char *kernel_cmdline,
> > +                           const char *initrd_filename,
> > +                           ram_addr_t below_4g_mem_size,
> > +                           PcGuestInfo *guest_info);
> >  FWCfgState *pc_memory_init(MachineState *machine,
> >                             MemoryRegion *system_memory,
> >                             ram_addr_t below_4g_mem_size,
> > -- 
> > 1.8.4.5
> >