[Qemu-devel] [PATCH v12 0/2] Add a generic loader

[Qemu-devel] [PATCH v12 0/2] Add a generic loader

[Alistair Francis]

This work is based on the original work by Li Guang with extra
features added by Peter C and myself.

The idea of this loader is to allow the user to load multiple images
or values into QEMU at startup.

Memory values can be loaded like this: -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4

Images can be loaded like this: -device loader,file=./images/u-boot.elf,cpu=0

This can be useful and we use it a lot in Xilinx to load multiple images
into a machine at creation (ATF, Kernel and DTB for example).

Tested with the latest Xilinx ZynqMP machine, if I enable EL3 and EL2 I can
boot ATF through to u-boot using the loader to load the images.

It can also be used to set registers.

This patch series makes the load_elf() function more generic by not
requiring an architecture. It also adds new functions load_elf_as(),
load_uimage_as and load_image_targphys_as which allows custom
AddressSpaces when loading images.

V12:
 - All patches have been reviewed
 - Most patches have been merged
 - The commit message of the actual device patch has been updated to
   justify why it is a device.


Alistair Francis (2):
  generic-loader: Add a generic loader
  docs: Add a generic loader explanation document

 MAINTAINERS                      |   6 ++
 docs/generic-loader.txt          |  81 ++++++++++++++++
 hw/core/Makefile.objs            |   2 +
 hw/core/generic-loader.c         | 197 +++++++++++++++++++++++++++++++++++++++
 include/hw/core/generic-loader.h |  46 +++++++++
 5 files changed, 332 insertions(+)
 create mode 100644 docs/generic-loader.txt
 create mode 100644 hw/core/generic-loader.c
 create mode 100644 include/hw/core/generic-loader.h

-- 
2.7.4

[Qemu-devel] [PATCH v12 1/2] generic-loader: Add a generic loader

[Alistair Francis]

Add a generic loader to QEMU which can be used to load images or set
memory values.

Internally inside QEMU this is a device. It is a strange device that
provides no hardware interface but allows QEMU to monkey patch memory
specified when it is created. To be able to do this it has a reset
callback that does the memory operations.

This device allows the user to monkey patch memory. To be able to do
this it needs a backend to manage the datas, the same as other
memory-related devices. In this case as the backend is so trivial we
have merged it with the frontend instead of creating and maintaining a
seperate backend.

Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
---
V12:
 - Update commit message to justify using -device
V11:
 - Small corrections
 - Don't check for !data as writing a value of 0 is valid.
V10:
 - Split out the PC setting and data loading
V9:
 - Fix error messages
 - Updated some incorrect logic
 - Add address space loading support for all image types
 - Explain why the reset is manually registered
V8:
 - Code corrections
 - Rebase
V7:
 - Rebase
V6:
 - Add error checking
V5:
 - Rebase
V4:
 - Allow the loader to work with every architecture
 - Move the file to hw/core
 - Increase the maximum number of CPUs
 - Make the CPU operations conditional
 - Convert the cpu option to cpu-num
 - Require the user to specify endianess
V3:
 - Pass the ram_size to load_image_targphys()
V2:
 - Add maintainers entry
 - Perform bounds checking
 - Register and unregister the reset in the realise/unrealise
Changes since RFC:
 - Add BE support

 MAINTAINERS                      |   6 ++
 hw/core/Makefile.objs            |   2 +
 hw/core/generic-loader.c         | 197 +++++++++++++++++++++++++++++++++++++++
 include/hw/core/generic-loader.h |  46 +++++++++
 4 files changed, 251 insertions(+)
 create mode 100644 hw/core/generic-loader.c
 create mode 100644 include/hw/core/generic-loader.h

diff --git a/MAINTAINERS b/MAINTAINERS
index f3c1f7f..9ecaaa5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1013,6 +1013,12 @@ M: Dmitry Fleytman <dmitry@daynix.com>
 S: Maintained
 F: hw/net/e1000e*
 
+Generic Loader
+M: Alistair Francis <alistair.francis@xilinx.com>
+S: Maintained
+F: hw/core/generic-loader.c
+F: include/hw/core/generic-loader.h
+
 Subsystems
 ----------
 Audio
diff --git a/hw/core/Makefile.objs b/hw/core/Makefile.objs
index cfd4840..939c94e 100644
--- a/hw/core/Makefile.objs
+++ b/hw/core/Makefile.objs
@@ -17,3 +17,5 @@ common-obj-$(CONFIG_SOFTMMU) += loader.o
 common-obj-$(CONFIG_SOFTMMU) += qdev-properties-system.o
 common-obj-$(CONFIG_SOFTMMU) += register.o
 common-obj-$(CONFIG_PLATFORM_BUS) += platform-bus.o
+
+obj-$(CONFIG_SOFTMMU) += generic-loader.o
diff --git a/hw/core/generic-loader.c b/hw/core/generic-loader.c
new file mode 100644
index 0000000..fc2fea7
--- /dev/null
+++ b/hw/core/generic-loader.c
@@ -0,0 +1,197 @@
+/*
+ * Generic Loader
+ *
+ * Copyright (C) 2014 Li Guang
+ * Copyright (C) 2016 Xilinx Inc.
+ * Written by Li Guang <lig.fnst@cn.fujitsu.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ */
+
+#include "qemu/osdep.h"
+#include "qom/cpu.h"
+#include "hw/sysbus.h"
+#include "sysemu/dma.h"
+#include "hw/loader.h"
+#include "qapi/error.h"
+#include "hw/core/generic-loader.h"
+
+#define CPU_NONE 0xFFFFFFFF
+
+static void generic_loader_reset(void *opaque)
+{
+    GenericLoaderState *s = GENERIC_LOADER(opaque);
+
+    if (s->set_pc) {
+        CPUClass *cc = CPU_GET_CLASS(s->cpu);
+        cpu_reset(s->cpu);
+        if (cc) {
+            cc->set_pc(s->cpu, s->addr);
+        }
+    }
+
+    if (s->data_len) {
+        assert(s->data_len < sizeof(s->data));
+        dma_memory_write(s->cpu->as, s->addr, &s->data, s->data_len);
+    }
+}
+
+static void generic_loader_realize(DeviceState *dev, Error **errp)
+{
+    GenericLoaderState *s = GENERIC_LOADER(dev);
+    hwaddr entry;
+    int big_endian;
+    int size = 0;
+
+    s->set_pc = false;
+
+    /* Perform some error checking on the user's options */
+    if (s->data || s->data_len  || s->data_be) {
+        /* User is loading memory values */
+        if (s->file) {
+            error_setg(errp, "Specifying a file is not supported when loading "
+                       "memory values");
+            return;
+        } else if (s->force_raw) {
+            error_setg(errp, "Specifying force-raw is not supported when "
+                       "loading memory values");
+            return;
+        } else if (!s->data_len) {
+            /* We cant' check for !data here as a value of 0 is still valid. */
+            error_setg(errp, "Both data and data-len must be specified");
+            return;
+        } else if (s->data_len > 8) {
+            error_setg(errp, "data-len cannot be greater then 8 bytes");
+            return;
+        }
+    } else if (s->file || s->force_raw)  {
+        /* User is loading an image */
+        if (s->data || s->data_len || s->data_be) {
+            error_setg(errp, "data can not be specified when loading an "
+                       "image");
+            return;
+        }
+        s->set_pc = true;
+    } else if (s->addr) {
+        /* User is setting the PC */
+        if (s->data || s->data_len || s->data_be) {
+            error_setg(errp, "data can not be specified when setting a "
+                       "program counter");
+            return;
+        } else if (!s->cpu_num) {
+            error_setg(errp, "cpu_num must be specified when setting a "
+                       "program counter");
+            return;
+        }
+        s->set_pc = true;
+    } else {
+        /* Did the user specify anything? */
+        error_setg(errp, "please include valid arguments");
+        return;
+    }
+
+    qemu_register_reset(generic_loader_reset, dev);
+
+    if (s->cpu_num != CPU_NONE) {
+        s->cpu = qemu_get_cpu(s->cpu_num);
+        if (!s->cpu) {
+            error_setg(errp, "Specified boot CPU#%d is nonexistent",
+                       s->cpu_num);
+            return;
+        }
+    } else {
+        s->cpu = first_cpu;
+    }
+
+#ifdef TARGET_WORDS_BIGENDIAN
+    big_endian = 1;
+#else
+    big_endian = 0;
+#endif
+
+    if (s->file) {
+        if (!s->force_raw) {
+            size = load_elf_as(s->file, NULL, NULL, &entry, NULL, NULL,
+                               big_endian, 0, 0, 0, s->cpu->as);
+
+            if (size < 0) {
+                size = load_uimage_as(s->file, &entry, NULL, NULL, NULL, NULL,
+                                      s->cpu->as);
+            }
+        }
+
+        if (size < 0 || s->force_raw) {
+            /* Default to the maximum size being the machine's ram size */
+            size = load_image_targphys_as(s->file, s->addr, ram_size,
+                                          s->cpu->as);
+        } else {
+            s->addr = entry;
+        }
+
+        if (size < 0) {
+            error_setg(errp, "Cannot load specified image %s", s->file);
+            return;
+        }
+    }
+
+    /* Convert the data endiannes */
+    if (s->data_be) {
+        s->data = cpu_to_be64(s->data);
+    } else {
+        s->data = cpu_to_le64(s->data);
+    }
+}
+
+static void generic_loader_unrealize(DeviceState *dev, Error **errp)
+{
+    qemu_unregister_reset(generic_loader_reset, dev);
+}
+
+static Property generic_loader_props[] = {
+    DEFINE_PROP_UINT64("addr", GenericLoaderState, addr, 0),
+    DEFINE_PROP_UINT64("data", GenericLoaderState, data, 0),
+    DEFINE_PROP_UINT8("data-len", GenericLoaderState, data_len, 0),
+    DEFINE_PROP_BOOL("data-be", GenericLoaderState, data_be, false),
+    DEFINE_PROP_UINT32("cpu-num", GenericLoaderState, cpu_num, CPU_NONE),
+    DEFINE_PROP_BOOL("force-raw", GenericLoaderState, force_raw, false),
+    DEFINE_PROP_STRING("file", GenericLoaderState, file),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void generic_loader_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+
+    /* The reset function is not registered here and is instead registered in
+     * the realize function to allow this device to be added via the device_add
+     * command in the QEMU monitor.
+     * TODO: Improve the device_add functionality to allow resets to be
+     * connected
+     */
+    dc->realize = generic_loader_realize;
+    dc->unrealize = generic_loader_unrealize;
+    dc->props = generic_loader_props;
+    dc->desc = "Generic Loader";
+}
+
+static TypeInfo generic_loader_info = {
+    .name = TYPE_GENERIC_LOADER,
+    .parent = TYPE_DEVICE,
+    .instance_size = sizeof(GenericLoaderState),
+    .class_init = generic_loader_class_init,
+};
+
+static void generic_loader_register_type(void)
+{
+    type_register_static(&generic_loader_info);
+}
+
+type_init(generic_loader_register_type)
diff --git a/include/hw/core/generic-loader.h b/include/hw/core/generic-loader.h
new file mode 100644
index 0000000..dd27c42
--- /dev/null
+++ b/include/hw/core/generic-loader.h
@@ -0,0 +1,46 @@
+/*
+ * Generic Loader
+ *
+ * Copyright (C) 2014 Li Guang
+ * Written by Li Guang <lig.fnst@cn.fujitsu.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ */
+
+#ifndef GENERIC_LOADER_H
+#define GENERIC_LOADER_H
+
+#include "elf.h"
+
+typedef struct GenericLoaderState {
+    /* <private> */
+    DeviceState parent_obj;
+
+    /* <public> */
+    CPUState *cpu;
+
+    uint64_t addr;
+    uint64_t data;
+    uint8_t data_len;
+    uint32_t cpu_num;
+
+    char *file;
+
+    bool force_raw;
+    bool data_be;
+    bool set_pc;
+} GenericLoaderState;
+
+#define TYPE_GENERIC_LOADER "loader"
+#define GENERIC_LOADER(obj) OBJECT_CHECK(GenericLoaderState, (obj), \
+                                         TYPE_GENERIC_LOADER)
+
+#endif
-- 
2.7.4

[Qemu-devel] [PATCH v12 2/2] docs: Add a generic loader explanation document

[Alistair Francis]

Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
---
V11:
 - Fix corrections
V10:
 - Split the data loading and PC setting
V9:
 - Clarify the image loading options
V8:
 - Improve documentation
V6:
 - Fixup documentation
V4:
 - Re-write to be more comprehensive

 docs/generic-loader.txt | 81 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 docs/generic-loader.txt

diff --git a/docs/generic-loader.txt b/docs/generic-loader.txt
new file mode 100644
index 0000000..d1f8ce3
--- /dev/null
+++ b/docs/generic-loader.txt
@@ -0,0 +1,81 @@
+Copyright (c) 2016 Xilinx Inc.
+
+This work is licensed under the terms of the GNU GPL, version 2 or later.  See
+the COPYING file in the top-level directory.
+
+
+The 'loader' device allows the user to load multiple images or values into
+QEMU at startup.
+
+Loading Data into Memory Values
+---------------------
+The loader device allows memory values to be set from the command line. This
+can be done by following the syntax below:
+
+     -device loader,addr=<addr>,data=<data>,data-len=<data-len>
+                   [,data-be=<data-be>][,cpu-num=<cpu-num>]
+
+    <addr>      - The address to store the data in.
+    <data>      - The value to be written to the address. The maximum size of
+                  the data is 8 bytes.
+    <data-len>  - The length of the data in bytes. This argument must be
+                  included if the data argument is.
+    <data-be>   - Set to true if the data to be stored on the guest should be
+                  written as big endian data. The default is to write little
+                  endian data.
+    <cpu-num>   - The number of the CPU's address space where the data should
+                  be loaded. If not specified the address space of the first
+                  CPU is used.
+
+For all values both hex and decimal values are allowed. By default the values
+will be parsed as decimal. To use hex values the user should prefix the number
+with a '0x'.
+
+An example of loading value 0x8000000e to address 0xfd1a0104 is:
+    -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4
+
+Setting a CPU's Program Counter
+---------------------
+The loader device allows the CPU's PC to be set from the command line. This
+can be done by following the syntax below:
+
+     -device loader,addr=<addr>,cpu-num=<cpu-num>
+
+    <addr>      - The value to use as the CPU's PC.
+    <cpu-num>   - The number of the CPU whose PC should be set to the
+                  specified value.
+
+For all values both hex and decimal values are allowed. By default the values
+will be parsed as decimal. To use hex values the user should prefix the number
+with a '0x'.
+
+An example of setting CPU 0's PC to 0x8000 is:
+    -device loader,addr=0x8000,cpu-num=0
+
+Loading Files
+---------------------
+The loader device also allows files to be loaded into memory. This can be done
+similarly to setting memory values. The syntax is shown below:
+
+    -device loader,file=<file>[,addr=<addr>][,cpu-num=<cpu-num>][,force-raw=<raw>]
+
+    <file>      - A file to be loaded into memory
+    <addr>      - The addr in memory that the file should be loaded. This is
+                  ignored if you are using an ELF (unless force-raw is true).
+                  This is required if you aren't loading an ELF.
+    <cpu-num>   - This specifies the CPU that should be used. This is an
+                  optional argument and will cause the CPU's PC to be set to
+                  where the image is stored or in the case of an ELF file to
+                  the value in the header. This option should only be used
+                  for the boot image.
+                  This will also cause the image to be written to the specified
+                  CPU's address space. If not specified, the default is CPU 0.
+    <force-raw> - Forces the file to be treated as a raw image. This can be
+                  used to specify the load address of ELF files.
+
+For all values both hex and decimal values are allowed. By default the values
+will be parsed as decimal. To use hex values the user should prefix the number
+with a '0x'.
+
+An example of loading an ELF file which CPU0 will boot is shown below:
+    -device loader,file=./images/boot.elf,cpu-num=0
-- 
2.7.4

Re: [Qemu-devel] [PATCH v12 0/2] Add a generic loader

[no-reply]

Hi,

Your series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.

Type: series
Message-id: cover.1475102513.git.alistair.francis@xilinx.com
Subject: [Qemu-devel] [PATCH v12 0/2]  Add a generic loader

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
make J=8 docker-test-quick@centos6
make J=8 docker-test-mingw@fedora
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
e1a89b7 docs: Add a generic loader explanation document
1826cff generic-loader: Add a generic loader

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 'dtc'...
Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf'
  BUILD centos6
=== OUTPUT END ===

Abort: command timeout (>3600 seconds)


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-devel@freelists.org

Re: [Qemu-devel] [PATCH v12 2/2] docs: Add a generic loader explanation document

[Markus Armbruster]

Alistair Francis <alistair.francis@xilinx.com> writes:

> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> V11:
>  - Fix corrections
> V10:
>  - Split the data loading and PC setting
> V9:
>  - Clarify the image loading options
> V8:
>  - Improve documentation
> V6:
>  - Fixup documentation
> V4:
>  - Re-write to be more comprehensive
>
>  docs/generic-loader.txt | 81 +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 81 insertions(+)
>  create mode 100644 docs/generic-loader.txt
>
> diff --git a/docs/generic-loader.txt b/docs/generic-loader.txt
> new file mode 100644
> index 0000000..d1f8ce3
> --- /dev/null
> +++ b/docs/generic-loader.txt
> @@ -0,0 +1,81 @@
> +Copyright (c) 2016 Xilinx Inc.
> +
> +This work is licensed under the terms of the GNU GPL, version 2 or later.  See
> +the COPYING file in the top-level directory.
> +
> +
> +The 'loader' device allows the user to load multiple images or values into
> +QEMU at startup.
> +
> +Loading Data into Memory Values
> +---------------------
> +The loader device allows memory values to be set from the command line. This
> +can be done by following the syntax below:
> +
> +     -device loader,addr=<addr>,data=<data>,data-len=<data-len>
> +                   [,data-be=<data-be>][,cpu-num=<cpu-num>]
> +
> +    <addr>      - The address to store the data in.
> +    <data>      - The value to be written to the address. The maximum size of
> +                  the data is 8 bytes.
> +    <data-len>  - The length of the data in bytes. This argument must be
> +                  included if the data argument is.
> +    <data-be>   - Set to true if the data to be stored on the guest should be
> +                  written as big endian data. The default is to write little
> +                  endian data.
> +    <cpu-num>   - The number of the CPU's address space where the data should
> +                  be loaded. If not specified the address space of the first
> +                  CPU is used.
> +
> +For all values both hex and decimal values are allowed. By default the values
> +will be parsed as decimal. To use hex values the user should prefix the number
> +with a '0x'.

Unless you bypassed QemuOpts number parsing somehow, octal works as
well.  In case you did bypass: don't!  Command line consistency matters.
Follow-up patch reverting the bypass would be required.

Not sure we want to document QemuOpts number syntax everywhere we
explain how a certain feature uses the command line.  A pointer to the
canonical place could be better.  Anyway, not something that needs
fixing before we commit.

> +
> +An example of loading value 0x8000000e to address 0xfd1a0104 is:
> +    -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4
> +
> +Setting a CPU's Program Counter
> +---------------------
> +The loader device allows the CPU's PC to be set from the command line. This
> +can be done by following the syntax below:
> +
> +     -device loader,addr=<addr>,cpu-num=<cpu-num>
> +
> +    <addr>      - The value to use as the CPU's PC.
> +    <cpu-num>   - The number of the CPU whose PC should be set to the
> +                  specified value.
> +
> +For all values both hex and decimal values are allowed. By default the values
> +will be parsed as decimal. To use hex values the user should prefix the number
> +with a '0x'.
> +
> +An example of setting CPU 0's PC to 0x8000 is:
> +    -device loader,addr=0x8000,cpu-num=0
> +
> +Loading Files
> +---------------------
> +The loader device also allows files to be loaded into memory. This can be done
> +similarly to setting memory values. The syntax is shown below:
> +
> +    -device loader,file=<file>[,addr=<addr>][,cpu-num=<cpu-num>][,force-raw=<raw>]
> +
> +    <file>      - A file to be loaded into memory
> +    <addr>      - The addr in memory that the file should be loaded. This is
> +                  ignored if you are using an ELF (unless force-raw is true).
> +                  This is required if you aren't loading an ELF.
> +    <cpu-num>   - This specifies the CPU that should be used. This is an
> +                  optional argument and will cause the CPU's PC to be set to
> +                  where the image is stored or in the case of an ELF file to
> +                  the value in the header. This option should only be used
> +                  for the boot image.
> +                  This will also cause the image to be written to the specified
> +                  CPU's address space. If not specified, the default is CPU 0.

Using @cpu-num both for further specifying the meaning of @addr and for
setting that CPU's PC is awkward.  Are you sure there will never be a
use case where you need to specify the CPU without also setting its PC?

To be clear: while I feel this is a question we must discuss and
resolve, I don't think we need to hold the series for it.

> +    <force-raw> - Forces the file to be treated as a raw image. This can be
> +                  used to specify the load address of ELF files.

"Specifying the load address of an ELF file" sounds like loading a
position-independent ELF file at a particular address.  But I guess this
is actually for loading a file raw even though it is recognized by QEMU
as ELF.

> +
> +For all values both hex and decimal values are allowed. By default the values
> +will be parsed as decimal. To use hex values the user should prefix the number
> +with a '0x'.
> +
> +An example of loading an ELF file which CPU0 will boot is shown below:
> +    -device loader,file=./images/boot.elf,cpu-num=0

Naive question: if you want to more than one thing (where "thing" is one
of the three cases described above), do you need a separate -device for
each, or can you combine them into one?


Again, while my questions may lead to improvements, they can be applied
on top.

Re: [Qemu-devel] [PATCH v12 0/2] Add a generic loader

[Markus Armbruster]

no-reply@ec2-52-6-146-230.compute-1.amazonaws.com writes:

> Hi,
>
> Your series failed automatic build test. Please find the testing commands and
> their output below. If you have docker installed, you can probably reproduce it
> locally.
>
> Type: series
> Message-id: cover.1475102513.git.alistair.francis@xilinx.com
> Subject: [Qemu-devel] [PATCH v12 0/2]  Add a generic loader
>
> === TEST SCRIPT BEGIN ===
> #!/bin/bash
> set -e
> git submodule update --init dtc
> # Let docker tests dump environment info
> export SHOW_ENV=1
> make J=8 docker-test-quick@centos6
> make J=8 docker-test-mingw@fedora
> === TEST SCRIPT END ===
>
> Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
> Switched to a new branch 'test'
> e1a89b7 docs: Add a generic loader explanation document
> 1826cff generic-loader: Add a generic loader
>
> === OUTPUT BEGIN ===
> Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
> Cloning into 'dtc'...
> Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf'
>   BUILD centos6
> === OUTPUT END ===
>
> Abort: command timeout (>3600 seconds)

Patchew hiccup or a real problem?

Re: [Qemu-devel] [PATCH v12 1/2] generic-loader: Add a generic loader

[Markus Armbruster]

Alistair Francis <alistair.francis@xilinx.com> writes:

> Add a generic loader to QEMU which can be used to load images or set
> memory values.
>
> Internally inside QEMU this is a device. It is a strange device that
> provides no hardware interface but allows QEMU to monkey patch memory
> specified when it is created. To be able to do this it has a reset
> callback that does the memory operations.
>
> This device allows the user to monkey patch memory. To be able to do
> this it needs a backend to manage the datas, the same as other
> memory-related devices. In this case as the backend is so trivial we
> have merged it with the frontend instead of creating and maintaining a
> seperate backend.

Works for me.

> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[...]
> diff --git a/hw/core/generic-loader.c b/hw/core/generic-loader.c
> new file mode 100644
> index 0000000..fc2fea7
> --- /dev/null
> +++ b/hw/core/generic-loader.c
> @@ -0,0 +1,197 @@
> +/*
> + * Generic Loader
> + *
> + * Copyright (C) 2014 Li Guang
> + * Copyright (C) 2016 Xilinx Inc.
> + * Written by Li Guang <lig.fnst@cn.fujitsu.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
> + * for more details.
> + */

The text you added to the commit message would make a lovely comment
here.  Please add it.

> +
> +#include "qemu/osdep.h"
> +#include "qom/cpu.h"
> +#include "hw/sysbus.h"
> +#include "sysemu/dma.h"
> +#include "hw/loader.h"
> +#include "qapi/error.h"
> +#include "hw/core/generic-loader.h"
[...]

Thank you very much for processing my much-too-late design review
graciously.

Acked-by: Markus Armbruster <armbru@redhat.com>

Re: [Qemu-devel] [PATCH v12 0/2] Add a generic loader

[Peter Maydell]

On 29 September 2016 at 02:25, Markus Armbruster <armbru@redhat.com> wrote:
> Patchew hiccup or a real problem?

Looks like a hiccup to me.

Can you let me know if you're happy with the new commit messages?
If so I'll apply these to target-arm.next.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v12 0/2] Add a generic loader

[Alistair Francis]

On Thu, Sep 29, 2016 at 5:00 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 29 September 2016 at 02:25, Markus Armbruster <armbru@redhat.com> wrote:
>> Patchew hiccup or a real problem?
>
> Looks like a hiccup to me.

Same, it looks like it can't clone dtc.

Thanks,

Alistair

>
> Can you let me know if you're happy with the new commit messages?
> If so I'll apply these to target-arm.next.
>
> thanks
> -- PMM
>

Re: [Qemu-devel] [PATCH v12 1/2] generic-loader: Add a generic loader

[Alistair Francis]

On Thu, Sep 29, 2016 at 2:32 AM, Markus Armbruster <armbru@redhat.com> wrote:
> Alistair Francis <alistair.francis@xilinx.com> writes:
>
>> Add a generic loader to QEMU which can be used to load images or set
>> memory values.
>>
>> Internally inside QEMU this is a device. It is a strange device that
>> provides no hardware interface but allows QEMU to monkey patch memory
>> specified when it is created. To be able to do this it has a reset
>> callback that does the memory operations.
>>
>> This device allows the user to monkey patch memory. To be able to do
>> this it needs a backend to manage the datas, the same as other
>> memory-related devices. In this case as the backend is so trivial we
>> have merged it with the frontend instead of creating and maintaining a
>> seperate backend.
>
> Works for me.

Great!

>
>> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
>> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
> [...]
>> diff --git a/hw/core/generic-loader.c b/hw/core/generic-loader.c
>> new file mode 100644
>> index 0000000..fc2fea7
>> --- /dev/null
>> +++ b/hw/core/generic-loader.c
>> @@ -0,0 +1,197 @@
>> +/*
>> + * Generic Loader
>> + *
>> + * Copyright (C) 2014 Li Guang
>> + * Copyright (C) 2016 Xilinx Inc.
>> + * Written by Li Guang <lig.fnst@cn.fujitsu.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License as published by the
>> + * Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
>> + * for more details.
>> + */
>
> The text you added to the commit message would make a lovely comment
> here.  Please add it.

Adding it in.

>
>> +
>> +#include "qemu/osdep.h"
>> +#include "qom/cpu.h"
>> +#include "hw/sysbus.h"
>> +#include "sysemu/dma.h"
>> +#include "hw/loader.h"
>> +#include "qapi/error.h"
>> +#include "hw/core/generic-loader.h"
> [...]
>
> Thank you very much for processing my much-too-late design review
> graciously.

No worries

>
> Acked-by: Markus Armbruster <armbru@redhat.com>

Thanks!

Alistair

>

Re: [Qemu-devel] [PATCH v12 0/2] Add a generic loader

[Peter Maydell]

On 29 September 2016 at 17:09, Alistair Francis
<alistair.francis@xilinx.com> wrote:
> On Thu, Sep 29, 2016 at 5:00 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 29 September 2016 at 02:25, Markus Armbruster <armbru@redhat.com> wrote:
>>> Patchew hiccup or a real problem?
>>
>> Looks like a hiccup to me.
>
> Same, it looks like it can't clone dtc

I think it cloned dtc but then hung after that; either way,
nothing to do with these patches.

-- PMM

Re: [Qemu-devel] [PATCH v12 2/2] docs: Add a generic loader explanation document

[Alistair Francis]

On Thu, Sep 29, 2016 at 2:24 AM, Markus Armbruster <armbru@redhat.com> wrote:
> Alistair Francis <alistair.francis@xilinx.com> writes:
>
>> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
>> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
>> ---
>> V11:
>>  - Fix corrections
>> V10:
>>  - Split the data loading and PC setting
>> V9:
>>  - Clarify the image loading options
>> V8:
>>  - Improve documentation
>> V6:
>>  - Fixup documentation
>> V4:
>>  - Re-write to be more comprehensive
>>
>>  docs/generic-loader.txt | 81 +++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 81 insertions(+)
>>  create mode 100644 docs/generic-loader.txt
>>
>> diff --git a/docs/generic-loader.txt b/docs/generic-loader.txt
>> new file mode 100644
>> index 0000000..d1f8ce3
>> --- /dev/null
>> +++ b/docs/generic-loader.txt
>> @@ -0,0 +1,81 @@
>> +Copyright (c) 2016 Xilinx Inc.
>> +
>> +This work is licensed under the terms of the GNU GPL, version 2 or later.  See
>> +the COPYING file in the top-level directory.
>> +
>> +
>> +The 'loader' device allows the user to load multiple images or values into
>> +QEMU at startup.
>> +
>> +Loading Data into Memory Values
>> +---------------------
>> +The loader device allows memory values to be set from the command line. This
>> +can be done by following the syntax below:
>> +
>> +     -device loader,addr=<addr>,data=<data>,data-len=<data-len>
>> +                   [,data-be=<data-be>][,cpu-num=<cpu-num>]
>> +
>> +    <addr>      - The address to store the data in.
>> +    <data>      - The value to be written to the address. The maximum size of
>> +                  the data is 8 bytes.
>> +    <data-len>  - The length of the data in bytes. This argument must be
>> +                  included if the data argument is.
>> +    <data-be>   - Set to true if the data to be stored on the guest should be
>> +                  written as big endian data. The default is to write little
>> +                  endian data.
>> +    <cpu-num>   - The number of the CPU's address space where the data should
>> +                  be loaded. If not specified the address space of the first
>> +                  CPU is used.
>> +
>> +For all values both hex and decimal values are allowed. By default the values
>> +will be parsed as decimal. To use hex values the user should prefix the number
>> +with a '0x'.
>
> Unless you bypassed QemuOpts number parsing somehow, octal works as
> well.  In case you did bypass: don't!  Command line consistency matters.
> Follow-up patch reverting the bypass would be required.
>
> Not sure we want to document QemuOpts number syntax everywhere we
> explain how a certain feature uses the command line.  A pointer to the
> canonical place could be better.  Anyway, not something that needs
> fixing before we commit.

I didn't bypass it, octal should work as well. I have clarified that a
bit in the doc.

>
>> +
>> +An example of loading value 0x8000000e to address 0xfd1a0104 is:
>> +    -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4
>> +
>> +Setting a CPU's Program Counter
>> +---------------------
>> +The loader device allows the CPU's PC to be set from the command line. This
>> +can be done by following the syntax below:
>> +
>> +     -device loader,addr=<addr>,cpu-num=<cpu-num>
>> +
>> +    <addr>      - The value to use as the CPU's PC.
>> +    <cpu-num>   - The number of the CPU whose PC should be set to the
>> +                  specified value.
>> +
>> +For all values both hex and decimal values are allowed. By default the values
>> +will be parsed as decimal. To use hex values the user should prefix the number
>> +with a '0x'.
>> +
>> +An example of setting CPU 0's PC to 0x8000 is:
>> +    -device loader,addr=0x8000,cpu-num=0
>> +
>> +Loading Files
>> +---------------------
>> +The loader device also allows files to be loaded into memory. This can be done
>> +similarly to setting memory values. The syntax is shown below:
>> +
>> +    -device loader,file=<file>[,addr=<addr>][,cpu-num=<cpu-num>][,force-raw=<raw>]
>> +
>> +    <file>      - A file to be loaded into memory
>> +    <addr>      - The addr in memory that the file should be loaded. This is
>> +                  ignored if you are using an ELF (unless force-raw is true).
>> +                  This is required if you aren't loading an ELF.
>> +    <cpu-num>   - This specifies the CPU that should be used. This is an
>> +                  optional argument and will cause the CPU's PC to be set to
>> +                  where the image is stored or in the case of an ELF file to
>> +                  the value in the header. This option should only be used
>> +                  for the boot image.
>> +                  This will also cause the image to be written to the specified
>> +                  CPU's address space. If not specified, the default is CPU 0.
>
> Using @cpu-num both for further specifying the meaning of @addr and for
> setting that CPU's PC is awkward.  Are you sure there will never be a
> use case where you need to specify the CPU without also setting its PC?
>
> To be clear: while I feel this is a question we must discuss and
> resolve, I don't think we need to hold the series for it.

I agree that this can occur. Internally in the loader framework is a
set_pc variable.

In the future we can make this user accessible and then allow that to
decide if the PC should be set or not.

>
>> +    <force-raw> - Forces the file to be treated as a raw image. This can be
>> +                  used to specify the load address of ELF files.
>
> "Specifying the load address of an ELF file" sounds like loading a
> position-independent ELF file at a particular address.  But I guess this
> is actually for loading a file raw even though it is recognized by QEMU
> as ELF.

This option basically does make an ELF file position-independent as
the user can control where it is loaded.

>
>> +
>> +For all values both hex and decimal values are allowed. By default the values
>> +will be parsed as decimal. To use hex values the user should prefix the number
>> +with a '0x'.
>> +
>> +An example of loading an ELF file which CPU0 will boot is shown below:
>> +    -device loader,file=./images/boot.elf,cpu-num=0
>
> Naive question: if you want to more than one thing (where "thing" is one
> of the three cases described above), do you need a separate -device for
> each, or can you combine them into one?

You can't really squash them together. If you wanted to set two
registers, you would need two commands.

Thanks,

Alistair

>
>
> Again, while my questions may lead to improvements, they can be applied
> on top.
>

Re: [Qemu-devel] [PATCH v12 0/2] Add a generic loader

[Alistair Francis]

On Thu, Sep 29, 2016 at 5:09 PM, Alistair Francis
<alistair.francis@xilinx.com> wrote:
> On Thu, Sep 29, 2016 at 5:00 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 29 September 2016 at 02:25, Markus Armbruster <armbru@redhat.com> wrote:
>>> Patchew hiccup or a real problem?
>>
>> Looks like a hiccup to me.
>
> Same, it looks like it can't clone dtc.
>
> Thanks,
>
> Alistair
>
>>
>> Can you let me know if you're happy with the new commit messages?
>> If so I'll apply these to target-arm.next.

I just sent out a V13 which include Markus's updates. It doesn't touch
any code, just updated the comments in the c file and re-words the
value passing in the doc.

Thanks,

Alistair

>>
>> thanks
>> -- PMM
>>

Re: [Qemu-devel] [PATCH v12 0/2] Add a generic loader

[Fam Zheng]

On Thu, 09/29 11:25, Markus Armbruster wrote:
> no-reply@ec2-52-6-146-230.compute-1.amazonaws.com writes:
> 
> > Hi,
> >
> > Your series failed automatic build test. Please find the testing commands and
> > their output below. If you have docker installed, you can probably reproduce it
> > locally.
> >
> > Type: series
> > Message-id: cover.1475102513.git.alistair.francis@xilinx.com
> > Subject: [Qemu-devel] [PATCH v12 0/2]  Add a generic loader
> >
> > === TEST SCRIPT BEGIN ===
> > #!/bin/bash
> > set -e
> > git submodule update --init dtc
> > # Let docker tests dump environment info
> > export SHOW_ENV=1
> > make J=8 docker-test-quick@centos6
> > make J=8 docker-test-mingw@fedora
> > === TEST SCRIPT END ===
> >
> > Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
> > Switched to a new branch 'test'
> > e1a89b7 docs: Add a generic loader explanation document
> > 1826cff generic-loader: Add a generic loader
> >
> > === OUTPUT BEGIN ===
> > Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
> > Cloning into 'dtc'...
> > Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf'
> >   BUILD centos6
> > === OUTPUT END ===
> >
> > Abort: command timeout (>3600 seconds)
> 
> Patchew hiccup or a real problem?

Likely a docker hiccup. The laste line being "BUILD centos6" means the "make
docker-test-quick@centos6" is hung. I don't know much more either. :(

Fam

Re: [Qemu-devel] [PATCH v12 2/2] docs: Add a generic loader explanation document

[Markus Armbruster]

Alistair Francis <alistair.francis@xilinx.com> writes:

> On Thu, Sep 29, 2016 at 2:24 AM, Markus Armbruster <armbru@redhat.com> wrote:
>> Alistair Francis <alistair.francis@xilinx.com> writes:
>>
>>> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
>>> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
>>> ---
>>> V11:
>>>  - Fix corrections
>>> V10:
>>>  - Split the data loading and PC setting
>>> V9:
>>>  - Clarify the image loading options
>>> V8:
>>>  - Improve documentation
>>> V6:
>>>  - Fixup documentation
>>> V4:
>>>  - Re-write to be more comprehensive
>>>
>>>  docs/generic-loader.txt | 81 +++++++++++++++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 81 insertions(+)
>>>  create mode 100644 docs/generic-loader.txt
>>>
>>> diff --git a/docs/generic-loader.txt b/docs/generic-loader.txt
>>> new file mode 100644
>>> index 0000000..d1f8ce3
>>> --- /dev/null
>>> +++ b/docs/generic-loader.txt
>>> @@ -0,0 +1,81 @@
>>> +Copyright (c) 2016 Xilinx Inc.
>>> +
>>> +This work is licensed under the terms of the GNU GPL, version 2 or later.  See
>>> +the COPYING file in the top-level directory.
>>> +
>>> +
>>> +The 'loader' device allows the user to load multiple images or values into
>>> +QEMU at startup.
>>> +
>>> +Loading Data into Memory Values
>>> +---------------------
>>> +The loader device allows memory values to be set from the command line. This
>>> +can be done by following the syntax below:
>>> +
>>> +     -device loader,addr=<addr>,data=<data>,data-len=<data-len>
>>> +                   [,data-be=<data-be>][,cpu-num=<cpu-num>]
>>> +
>>> +    <addr>      - The address to store the data in.
>>> +    <data>      - The value to be written to the address. The maximum size of
>>> +                  the data is 8 bytes.
>>> +    <data-len>  - The length of the data in bytes. This argument must be
>>> +                  included if the data argument is.
>>> +    <data-be>   - Set to true if the data to be stored on the guest should be
>>> +                  written as big endian data. The default is to write little
>>> +                  endian data.
>>> +    <cpu-num>   - The number of the CPU's address space where the data should
>>> +                  be loaded. If not specified the address space of the first
>>> +                  CPU is used.
>>> +
>>> +For all values both hex and decimal values are allowed. By default the values
>>> +will be parsed as decimal. To use hex values the user should prefix the number
>>> +with a '0x'.
>>
>> Unless you bypassed QemuOpts number parsing somehow, octal works as
>> well.  In case you did bypass: don't!  Command line consistency matters.
>> Follow-up patch reverting the bypass would be required.
>>
>> Not sure we want to document QemuOpts number syntax everywhere we
>> explain how a certain feature uses the command line.  A pointer to the
>> canonical place could be better.  Anyway, not something that needs
>> fixing before we commit.
>
> I didn't bypass it, octal should work as well. I have clarified that a
> bit in the doc.

Thanks.

>>> +
>>> +An example of loading value 0x8000000e to address 0xfd1a0104 is:
>>> +    -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4
>>> +
>>> +Setting a CPU's Program Counter
>>> +---------------------
>>> +The loader device allows the CPU's PC to be set from the command line. This
>>> +can be done by following the syntax below:
>>> +
>>> +     -device loader,addr=<addr>,cpu-num=<cpu-num>
>>> +
>>> +    <addr>      - The value to use as the CPU's PC.
>>> +    <cpu-num>   - The number of the CPU whose PC should be set to the
>>> +                  specified value.
>>> +
>>> +For all values both hex and decimal values are allowed. By default the values
>>> +will be parsed as decimal. To use hex values the user should prefix the number
>>> +with a '0x'.
>>> +
>>> +An example of setting CPU 0's PC to 0x8000 is:
>>> +    -device loader,addr=0x8000,cpu-num=0
>>> +
>>> +Loading Files
>>> +---------------------
>>> +The loader device also allows files to be loaded into memory. This can be done
>>> +similarly to setting memory values. The syntax is shown below:
>>> +
>>> +    -device loader,file=<file>[,addr=<addr>][,cpu-num=<cpu-num>][,force-raw=<raw>]
>>> +
>>> +    <file>      - A file to be loaded into memory
>>> +    <addr>      - The addr in memory that the file should be loaded. This is
>>> +                  ignored if you are using an ELF (unless force-raw is true).
>>> +                  This is required if you aren't loading an ELF.
>>> +    <cpu-num>   - This specifies the CPU that should be used. This is an
>>> +                  optional argument and will cause the CPU's PC to be set to
>>> +                  where the image is stored or in the case of an ELF file to
>>> +                  the value in the header. This option should only be used
>>> +                  for the boot image.
>>> +                  This will also cause the image to be written to the specified
>>> +                  CPU's address space. If not specified, the default is CPU 0.
>>
>> Using @cpu-num both for further specifying the meaning of @addr and for
>> setting that CPU's PC is awkward.  Are you sure there will never be a
>> use case where you need to specify the CPU without also setting its PC?
>>
>> To be clear: while I feel this is a question we must discuss and
>> resolve, I don't think we need to hold the series for it.
>
> I agree that this can occur. Internally in the loader framework is a
> set_pc variable.
>
> In the future we can make this user accessible and then allow that to
> decide if the PC should be set or not.

If you can't do it right away, please document it as restriction, and
add a TODO comment to lift it.

>>> +    <force-raw> - Forces the file to be treated as a raw image. This can be
>>> +                  used to specify the load address of ELF files.
>>
>> "Specifying the load address of an ELF file" sounds like loading a
>> position-independent ELF file at a particular address.  But I guess this
>> is actually for loading a file raw even though it is recognized by QEMU
>> as ELF.
>
> This option basically does make an ELF file position-independent as
> the user can control where it is loaded.

Aha.  Then the name "force-raw" is confusing.

>>> +
>>> +For all values both hex and decimal values are allowed. By default the values
>>> +will be parsed as decimal. To use hex values the user should prefix the number
>>> +with a '0x'.
>>> +
>>> +An example of loading an ELF file which CPU0 will boot is shown below:
>>> +    -device loader,file=./images/boot.elf,cpu-num=0
>>
>> Naive question: if you want to more than one thing (where "thing" is one
>> of the three cases described above), do you need a separate -device for
>> each, or can you combine them into one?
>
> You can't really squash them together. If you wanted to set two
> registers, you would need two commands.

That's okay.  It just isn't quite obvious to me in the text.

>
> Thanks,
>
> Alistair
>
>>
>>
>> Again, while my questions may lead to improvements, they can be applied
>> on top.
>>

Re: [Qemu-devel] [PATCH v12 2/2] docs: Add a generic loader explanation document

[Alistair Francis]

On Thu, Sep 29, 2016 at 10:36 PM, Markus Armbruster <armbru@redhat.com> wrote:
> Alistair Francis <alistair.francis@xilinx.com> writes:
>
>> On Thu, Sep 29, 2016 at 2:24 AM, Markus Armbruster <armbru@redhat.com> wrote:
>>> Alistair Francis <alistair.francis@xilinx.com> writes:
>>>
>>>> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
>>>> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
>>>> ---
>>>> V11:
>>>>  - Fix corrections
>>>> V10:
>>>>  - Split the data loading and PC setting
>>>> V9:
>>>>  - Clarify the image loading options
>>>> V8:
>>>>  - Improve documentation
>>>> V6:
>>>>  - Fixup documentation
>>>> V4:
>>>>  - Re-write to be more comprehensive
>>>>
>>>>  docs/generic-loader.txt | 81 +++++++++++++++++++++++++++++++++++++++++++++++++
>>>>  1 file changed, 81 insertions(+)
>>>>  create mode 100644 docs/generic-loader.txt
>>>>
>>>> diff --git a/docs/generic-loader.txt b/docs/generic-loader.txt
>>>> new file mode 100644
>>>> index 0000000..d1f8ce3
>>>> --- /dev/null
>>>> +++ b/docs/generic-loader.txt
>>>> @@ -0,0 +1,81 @@
>>>> +Copyright (c) 2016 Xilinx Inc.
>>>> +
>>>> +This work is licensed under the terms of the GNU GPL, version 2 or later.  See
>>>> +the COPYING file in the top-level directory.
>>>> +
>>>> +
>>>> +The 'loader' device allows the user to load multiple images or values into
>>>> +QEMU at startup.
>>>> +
>>>> +Loading Data into Memory Values
>>>> +---------------------
>>>> +The loader device allows memory values to be set from the command line. This
>>>> +can be done by following the syntax below:
>>>> +
>>>> +     -device loader,addr=<addr>,data=<data>,data-len=<data-len>
>>>> +                   [,data-be=<data-be>][,cpu-num=<cpu-num>]
>>>> +
>>>> +    <addr>      - The address to store the data in.
>>>> +    <data>      - The value to be written to the address. The maximum size of
>>>> +                  the data is 8 bytes.
>>>> +    <data-len>  - The length of the data in bytes. This argument must be
>>>> +                  included if the data argument is.
>>>> +    <data-be>   - Set to true if the data to be stored on the guest should be
>>>> +                  written as big endian data. The default is to write little
>>>> +                  endian data.
>>>> +    <cpu-num>   - The number of the CPU's address space where the data should
>>>> +                  be loaded. If not specified the address space of the first
>>>> +                  CPU is used.
>>>> +
>>>> +For all values both hex and decimal values are allowed. By default the values
>>>> +will be parsed as decimal. To use hex values the user should prefix the number
>>>> +with a '0x'.
>>>
>>> Unless you bypassed QemuOpts number parsing somehow, octal works as
>>> well.  In case you did bypass: don't!  Command line consistency matters.
>>> Follow-up patch reverting the bypass would be required.
>>>
>>> Not sure we want to document QemuOpts number syntax everywhere we
>>> explain how a certain feature uses the command line.  A pointer to the
>>> canonical place could be better.  Anyway, not something that needs
>>> fixing before we commit.
>>
>> I didn't bypass it, octal should work as well. I have clarified that a
>> bit in the doc.
>
> Thanks.
>
>>>> +
>>>> +An example of loading value 0x8000000e to address 0xfd1a0104 is:
>>>> +    -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4
>>>> +
>>>> +Setting a CPU's Program Counter
>>>> +---------------------
>>>> +The loader device allows the CPU's PC to be set from the command line. This
>>>> +can be done by following the syntax below:
>>>> +
>>>> +     -device loader,addr=<addr>,cpu-num=<cpu-num>
>>>> +
>>>> +    <addr>      - The value to use as the CPU's PC.
>>>> +    <cpu-num>   - The number of the CPU whose PC should be set to the
>>>> +                  specified value.
>>>> +
>>>> +For all values both hex and decimal values are allowed. By default the values
>>>> +will be parsed as decimal. To use hex values the user should prefix the number
>>>> +with a '0x'.
>>>> +
>>>> +An example of setting CPU 0's PC to 0x8000 is:
>>>> +    -device loader,addr=0x8000,cpu-num=0
>>>> +
>>>> +Loading Files
>>>> +---------------------
>>>> +The loader device also allows files to be loaded into memory. This can be done
>>>> +similarly to setting memory values. The syntax is shown below:
>>>> +
>>>> +    -device loader,file=<file>[,addr=<addr>][,cpu-num=<cpu-num>][,force-raw=<raw>]
>>>> +
>>>> +    <file>      - A file to be loaded into memory
>>>> +    <addr>      - The addr in memory that the file should be loaded. This is
>>>> +                  ignored if you are using an ELF (unless force-raw is true).
>>>> +                  This is required if you aren't loading an ELF.
>>>> +    <cpu-num>   - This specifies the CPU that should be used. This is an
>>>> +                  optional argument and will cause the CPU's PC to be set to
>>>> +                  where the image is stored or in the case of an ELF file to
>>>> +                  the value in the header. This option should only be used
>>>> +                  for the boot image.
>>>> +                  This will also cause the image to be written to the specified
>>>> +                  CPU's address space. If not specified, the default is CPU 0.
>>>
>>> Using @cpu-num both for further specifying the meaning of @addr and for
>>> setting that CPU's PC is awkward.  Are you sure there will never be a
>>> use case where you need to specify the CPU without also setting its PC?
>>>
>>> To be clear: while I feel this is a question we must discuss and
>>> resolve, I don't think we need to hold the series for it.
>>
>> I agree that this can occur. Internally in the loader framework is a
>> set_pc variable.
>>
>> In the future we can make this user accessible and then allow that to
>> decide if the PC should be set or not.
>
> If you can't do it right away, please document it as restriction, and
> add a TODO comment to lift it.

I have a patch that adds known restrictions.

>
>>>> +    <force-raw> - Forces the file to be treated as a raw image. This can be
>>>> +                  used to specify the load address of ELF files.
>>>
>>> "Specifying the load address of an ELF file" sounds like loading a
>>> position-independent ELF file at a particular address.  But I guess this
>>> is actually for loading a file raw even though it is recognized by QEMU
>>> as ELF.
>>
>> This option basically does make an ELF file position-independent as
>> the user can control where it is loaded.
>
> Aha.  Then the name "force-raw" is confusing.

I disagree. It tells QEMU to treat the image as just a dumb blob,
instead of loading it as and ELF file. I thin force-raw makes sense as
the user is telling QEMU that the image should be treated as a raw
image, no matter what it actually is.

Thanks,

Alistair

>
>>>> +
>>>> +For all values both hex and decimal values are allowed. By default the values
>>>> +will be parsed as decimal. To use hex values the user should prefix the number
>>>> +with a '0x'.
>>>> +
>>>> +An example of loading an ELF file which CPU0 will boot is shown below:
>>>> +    -device loader,file=./images/boot.elf,cpu-num=0
>>>
>>> Naive question: if you want to more than one thing (where "thing" is one
>>> of the three cases described above), do you need a separate -device for
>>> each, or can you combine them into one?
>>
>> You can't really squash them together. If you wanted to set two
>> registers, you would need two commands.
>
> That's okay.  It just isn't quite obvious to me in the text.
>
>>
>> Thanks,
>>
>> Alistair
>>
>>>
>>>
>>> Again, while my questions may lead to improvements, they can be applied
>>> on top.
>>>
>

Re: [Qemu-devel] [PATCH v12 2/2] docs: Add a generic loader explanation document

[Markus Armbruster]

Alistair Francis <alistair.francis@xilinx.com> writes:

> On Thu, Sep 29, 2016 at 10:36 PM, Markus Armbruster <armbru@redhat.com> wrote:
>> Alistair Francis <alistair.francis@xilinx.com> writes:
>>
>>> On Thu, Sep 29, 2016 at 2:24 AM, Markus Armbruster <armbru@redhat.com> wrote:
>>>> Alistair Francis <alistair.francis@xilinx.com> writes:
>>>>
>>>>> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
>>>>> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
>>>>> ---
>>>>> V11:
>>>>>  - Fix corrections
>>>>> V10:
>>>>>  - Split the data loading and PC setting
>>>>> V9:
>>>>>  - Clarify the image loading options
>>>>> V8:
>>>>>  - Improve documentation
>>>>> V6:
>>>>>  - Fixup documentation
>>>>> V4:
>>>>>  - Re-write to be more comprehensive
>>>>>
>>>>>  docs/generic-loader.txt | 81 +++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>  1 file changed, 81 insertions(+)
>>>>>  create mode 100644 docs/generic-loader.txt
>>>>>
>>>>> diff --git a/docs/generic-loader.txt b/docs/generic-loader.txt
>>>>> new file mode 100644
>>>>> index 0000000..d1f8ce3
>>>>> --- /dev/null
>>>>> +++ b/docs/generic-loader.txt
>>>>> @@ -0,0 +1,81 @@
>>>>> +Copyright (c) 2016 Xilinx Inc.
>>>>> +
>>>>> +This work is licensed under the terms of the GNU GPL, version 2 or later.  See
>>>>> +the COPYING file in the top-level directory.
>>>>> +
>>>>> +
>>>>> +The 'loader' device allows the user to load multiple images or values into
>>>>> +QEMU at startup.
>>>>> +
>>>>> +Loading Data into Memory Values
>>>>> +---------------------
>>>>> +The loader device allows memory values to be set from the command line. This
>>>>> +can be done by following the syntax below:
>>>>> +
>>>>> +     -device loader,addr=<addr>,data=<data>,data-len=<data-len>
>>>>> +                   [,data-be=<data-be>][,cpu-num=<cpu-num>]
>>>>> +
>>>>> +    <addr>      - The address to store the data in.
>>>>> +    <data>      - The value to be written to the address. The maximum size of
>>>>> +                  the data is 8 bytes.
>>>>> +    <data-len>  - The length of the data in bytes. This argument must be
>>>>> +                  included if the data argument is.
>>>>> +    <data-be>   - Set to true if the data to be stored on the guest should be
>>>>> +                  written as big endian data. The default is to write little
>>>>> +                  endian data.
>>>>> +    <cpu-num>   - The number of the CPU's address space where the data should
>>>>> +                  be loaded. If not specified the address space of the first
>>>>> +                  CPU is used.
>>>>> +
>>>>> +For all values both hex and decimal values are allowed. By default the values
>>>>> +will be parsed as decimal. To use hex values the user should prefix the number
>>>>> +with a '0x'.
>>>>
>>>> Unless you bypassed QemuOpts number parsing somehow, octal works as
>>>> well.  In case you did bypass: don't!  Command line consistency matters.
>>>> Follow-up patch reverting the bypass would be required.
>>>>
>>>> Not sure we want to document QemuOpts number syntax everywhere we
>>>> explain how a certain feature uses the command line.  A pointer to the
>>>> canonical place could be better.  Anyway, not something that needs
>>>> fixing before we commit.
>>>
>>> I didn't bypass it, octal should work as well. I have clarified that a
>>> bit in the doc.
>>
>> Thanks.
>>
>>>>> +
>>>>> +An example of loading value 0x8000000e to address 0xfd1a0104 is:
>>>>> +    -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4
>>>>> +
>>>>> +Setting a CPU's Program Counter
>>>>> +---------------------
>>>>> +The loader device allows the CPU's PC to be set from the command line. This
>>>>> +can be done by following the syntax below:
>>>>> +
>>>>> +     -device loader,addr=<addr>,cpu-num=<cpu-num>
>>>>> +
>>>>> +    <addr>      - The value to use as the CPU's PC.
>>>>> +    <cpu-num>   - The number of the CPU whose PC should be set to the
>>>>> +                  specified value.
>>>>> +
>>>>> +For all values both hex and decimal values are allowed. By default the values
>>>>> +will be parsed as decimal. To use hex values the user should prefix the number
>>>>> +with a '0x'.
>>>>> +
>>>>> +An example of setting CPU 0's PC to 0x8000 is:
>>>>> +    -device loader,addr=0x8000,cpu-num=0
>>>>> +
>>>>> +Loading Files
>>>>> +---------------------
>>>>> +The loader device also allows files to be loaded into memory. This can be done
>>>>> +similarly to setting memory values. The syntax is shown below:
>>>>> +
>>>>> +    -device loader,file=<file>[,addr=<addr>][,cpu-num=<cpu-num>][,force-raw=<raw>]
>>>>> +
>>>>> +    <file>      - A file to be loaded into memory
>>>>> +    <addr>      - The addr in memory that the file should be loaded. This is
>>>>> +                  ignored if you are using an ELF (unless force-raw is true).
>>>>> +                  This is required if you aren't loading an ELF.
>>>>> +    <cpu-num>   - This specifies the CPU that should be used. This is an
>>>>> +                  optional argument and will cause the CPU's PC to be set to
>>>>> +                  where the image is stored or in the case of an ELF file to
>>>>> +                  the value in the header. This option should only be used
>>>>> +                  for the boot image.
>>>>> +                  This will also cause the image to be written to the specified
>>>>> +                  CPU's address space. If not specified, the default is CPU 0.
>>>>
>>>> Using @cpu-num both for further specifying the meaning of @addr and for
>>>> setting that CPU's PC is awkward.  Are you sure there will never be a
>>>> use case where you need to specify the CPU without also setting its PC?
>>>>
>>>> To be clear: while I feel this is a question we must discuss and
>>>> resolve, I don't think we need to hold the series for it.
>>>
>>> I agree that this can occur. Internally in the loader framework is a
>>> set_pc variable.
>>>
>>> In the future we can make this user accessible and then allow that to
>>> decide if the PC should be set or not.
>>
>> If you can't do it right away, please document it as restriction, and
>> add a TODO comment to lift it.
>
> I have a patch that adds known restrictions.
>
>>
>>>>> +    <force-raw> - Forces the file to be treated as a raw image. This can be
>>>>> +                  used to specify the load address of ELF files.
>>>>
>>>> "Specifying the load address of an ELF file" sounds like loading a
>>>> position-independent ELF file at a particular address.  But I guess this
>>>> is actually for loading a file raw even though it is recognized by QEMU
>>>> as ELF.
>>>
>>> This option basically does make an ELF file position-independent as
>>> the user can control where it is loaded.
>>
>> Aha.  Then the name "force-raw" is confusing.
>
> I disagree. It tells QEMU to treat the image as just a dumb blob,
> instead of loading it as and ELF file. I thin force-raw makes sense as
> the user is telling QEMU that the image should be treated as a raw
> image, no matter what it actually is.

I'm still confused then.

I can see two possible features here, and based on your documentation
and commentary, I can't tell which one you implemented:

0. QEMU can load raw files and ELF executable files.  Raw files are
loaded verbatim at a the specified address.  ELF executable files are
loaded by an ELF loader, which loads the program header table's loadable
segments.

1. force-raw overrides the ELF detection, to let you load an ELF
executable file verbatim, as if it was raw.

2. force-raw lets you overrides the ELF file's load address: the ELF
loader uses the specified address instead of the address contained in
the ELF file.

Which one is it?  Your latest answer strongly suggests 1, but prior
answers have made me suspect 2.

Re: [Qemu-devel] [PATCH v12 2/2] docs: Add a generic loader explanation document

[Alistair Francis]

On Tue, Oct 4, 2016 at 12:56 AM, Markus Armbruster <armbru@redhat.com> wrote:
> Alistair Francis <alistair.francis@xilinx.com> writes:
>
>> On Thu, Sep 29, 2016 at 10:36 PM, Markus Armbruster <armbru@redhat.com> wrote:
>>> Alistair Francis <alistair.francis@xilinx.com> writes:
>>>
>>>> On Thu, Sep 29, 2016 at 2:24 AM, Markus Armbruster <armbru@redhat.com> wrote:
>>>>> Alistair Francis <alistair.francis@xilinx.com> writes:
>>>>>
>>>>>> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
>>>>>> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
>>>>>> ---
>>>>>> V11:
>>>>>>  - Fix corrections
>>>>>> V10:
>>>>>>  - Split the data loading and PC setting
>>>>>> V9:
>>>>>>  - Clarify the image loading options
>>>>>> V8:
>>>>>>  - Improve documentation
>>>>>> V6:
>>>>>>  - Fixup documentation
>>>>>> V4:
>>>>>>  - Re-write to be more comprehensive
>>>>>>
>>>>>>  docs/generic-loader.txt | 81 +++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>  1 file changed, 81 insertions(+)
>>>>>>  create mode 100644 docs/generic-loader.txt
>>>>>>
>>>>>> diff --git a/docs/generic-loader.txt b/docs/generic-loader.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..d1f8ce3
>>>>>> --- /dev/null
>>>>>> +++ b/docs/generic-loader.txt
>>>>>> @@ -0,0 +1,81 @@
>>>>>> +Copyright (c) 2016 Xilinx Inc.
>>>>>> +
>>>>>> +This work is licensed under the terms of the GNU GPL, version 2 or later.  See
>>>>>> +the COPYING file in the top-level directory.
>>>>>> +
>>>>>> +
>>>>>> +The 'loader' device allows the user to load multiple images or values into
>>>>>> +QEMU at startup.
>>>>>> +
>>>>>> +Loading Data into Memory Values
>>>>>> +---------------------
>>>>>> +The loader device allows memory values to be set from the command line. This
>>>>>> +can be done by following the syntax below:
>>>>>> +
>>>>>> +     -device loader,addr=<addr>,data=<data>,data-len=<data-len>
>>>>>> +                   [,data-be=<data-be>][,cpu-num=<cpu-num>]
>>>>>> +
>>>>>> +    <addr>      - The address to store the data in.
>>>>>> +    <data>      - The value to be written to the address. The maximum size of
>>>>>> +                  the data is 8 bytes.
>>>>>> +    <data-len>  - The length of the data in bytes. This argument must be
>>>>>> +                  included if the data argument is.
>>>>>> +    <data-be>   - Set to true if the data to be stored on the guest should be
>>>>>> +                  written as big endian data. The default is to write little
>>>>>> +                  endian data.
>>>>>> +    <cpu-num>   - The number of the CPU's address space where the data should
>>>>>> +                  be loaded. If not specified the address space of the first
>>>>>> +                  CPU is used.
>>>>>> +
>>>>>> +For all values both hex and decimal values are allowed. By default the values
>>>>>> +will be parsed as decimal. To use hex values the user should prefix the number
>>>>>> +with a '0x'.
>>>>>
>>>>> Unless you bypassed QemuOpts number parsing somehow, octal works as
>>>>> well.  In case you did bypass: don't!  Command line consistency matters.
>>>>> Follow-up patch reverting the bypass would be required.
>>>>>
>>>>> Not sure we want to document QemuOpts number syntax everywhere we
>>>>> explain how a certain feature uses the command line.  A pointer to the
>>>>> canonical place could be better.  Anyway, not something that needs
>>>>> fixing before we commit.
>>>>
>>>> I didn't bypass it, octal should work as well. I have clarified that a
>>>> bit in the doc.
>>>
>>> Thanks.
>>>
>>>>>> +
>>>>>> +An example of loading value 0x8000000e to address 0xfd1a0104 is:
>>>>>> +    -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4
>>>>>> +
>>>>>> +Setting a CPU's Program Counter
>>>>>> +---------------------
>>>>>> +The loader device allows the CPU's PC to be set from the command line. This
>>>>>> +can be done by following the syntax below:
>>>>>> +
>>>>>> +     -device loader,addr=<addr>,cpu-num=<cpu-num>
>>>>>> +
>>>>>> +    <addr>      - The value to use as the CPU's PC.
>>>>>> +    <cpu-num>   - The number of the CPU whose PC should be set to the
>>>>>> +                  specified value.
>>>>>> +
>>>>>> +For all values both hex and decimal values are allowed. By default the values
>>>>>> +will be parsed as decimal. To use hex values the user should prefix the number
>>>>>> +with a '0x'.
>>>>>> +
>>>>>> +An example of setting CPU 0's PC to 0x8000 is:
>>>>>> +    -device loader,addr=0x8000,cpu-num=0
>>>>>> +
>>>>>> +Loading Files
>>>>>> +---------------------
>>>>>> +The loader device also allows files to be loaded into memory. This can be done
>>>>>> +similarly to setting memory values. The syntax is shown below:
>>>>>> +
>>>>>> +    -device loader,file=<file>[,addr=<addr>][,cpu-num=<cpu-num>][,force-raw=<raw>]
>>>>>> +
>>>>>> +    <file>      - A file to be loaded into memory
>>>>>> +    <addr>      - The addr in memory that the file should be loaded. This is
>>>>>> +                  ignored if you are using an ELF (unless force-raw is true).
>>>>>> +                  This is required if you aren't loading an ELF.
>>>>>> +    <cpu-num>   - This specifies the CPU that should be used. This is an
>>>>>> +                  optional argument and will cause the CPU's PC to be set to
>>>>>> +                  where the image is stored or in the case of an ELF file to
>>>>>> +                  the value in the header. This option should only be used
>>>>>> +                  for the boot image.
>>>>>> +                  This will also cause the image to be written to the specified
>>>>>> +                  CPU's address space. If not specified, the default is CPU 0.
>>>>>
>>>>> Using @cpu-num both for further specifying the meaning of @addr and for
>>>>> setting that CPU's PC is awkward.  Are you sure there will never be a
>>>>> use case where you need to specify the CPU without also setting its PC?
>>>>>
>>>>> To be clear: while I feel this is a question we must discuss and
>>>>> resolve, I don't think we need to hold the series for it.
>>>>
>>>> I agree that this can occur. Internally in the loader framework is a
>>>> set_pc variable.
>>>>
>>>> In the future we can make this user accessible and then allow that to
>>>> decide if the PC should be set or not.
>>>
>>> If you can't do it right away, please document it as restriction, and
>>> add a TODO comment to lift it.
>>
>> I have a patch that adds known restrictions.
>>
>>>
>>>>>> +    <force-raw> - Forces the file to be treated as a raw image. This can be
>>>>>> +                  used to specify the load address of ELF files.
>>>>>
>>>>> "Specifying the load address of an ELF file" sounds like loading a
>>>>> position-independent ELF file at a particular address.  But I guess this
>>>>> is actually for loading a file raw even though it is recognized by QEMU
>>>>> as ELF.
>>>>
>>>> This option basically does make an ELF file position-independent as
>>>> the user can control where it is loaded.
>>>
>>> Aha.  Then the name "force-raw" is confusing.
>>
>> I disagree. It tells QEMU to treat the image as just a dumb blob,
>> instead of loading it as and ELF file. I thin force-raw makes sense as
>> the user is telling QEMU that the image should be treated as a raw
>> image, no matter what it actually is.
>
> I'm still confused then.
>
> I can see two possible features here, and based on your documentation
> and commentary, I can't tell which one you implemented:
>
> 0. QEMU can load raw files and ELF executable files.  Raw files are
> loaded verbatim at a the specified address.  ELF executable files are
> loaded by an ELF loader, which loads the program header table's loadable
> segments.
>
> 1. force-raw overrides the ELF detection, to let you load an ELF
> executable file verbatim, as if it was raw.

This is what the option does. It forces the image to be treated as a raw image.

I'm sorry if I implied it was option 2 instead.

Thanks,

Alistair

>
> 2. force-raw lets you overrides the ELF file's load address: the ELF
> loader uses the specified address instead of the address contained in
> the ELF file.
>
> Which one is it?  Your latest answer strongly suggests 1, but prior
> answers have made me suspect 2.
>

Re: [Qemu-devel] [PATCH v12 2/2] docs: Add a generic loader explanation document

[Markus Armbruster]

Alistair Francis <alistair.francis@xilinx.com> writes:

> On Tue, Oct 4, 2016 at 12:56 AM, Markus Armbruster <armbru@redhat.com> wrote:
>> Alistair Francis <alistair.francis@xilinx.com> writes:
>>
>>> On Thu, Sep 29, 2016 at 10:36 PM, Markus Armbruster <armbru@redhat.com> wrote:
>>>> Alistair Francis <alistair.francis@xilinx.com> writes:
>>>>
>>>>> On Thu, Sep 29, 2016 at 2:24 AM, Markus Armbruster <armbru@redhat.com> wrote:
>>>>>> Alistair Francis <alistair.francis@xilinx.com> writes:
>>>>>>
>>>>>>> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
>>>>>>> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
>>>>>>> ---
>>>>>>> V11:
>>>>>>>  - Fix corrections
>>>>>>> V10:
>>>>>>>  - Split the data loading and PC setting
>>>>>>> V9:
>>>>>>>  - Clarify the image loading options
>>>>>>> V8:
>>>>>>>  - Improve documentation
>>>>>>> V6:
>>>>>>>  - Fixup documentation
>>>>>>> V4:
>>>>>>>  - Re-write to be more comprehensive
>>>>>>>
>>>>>>>  docs/generic-loader.txt | 81 +++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>>  1 file changed, 81 insertions(+)
>>>>>>>  create mode 100644 docs/generic-loader.txt
>>>>>>>
>>>>>>> diff --git a/docs/generic-loader.txt b/docs/generic-loader.txt
>>>>>>> new file mode 100644
>>>>>>> index 0000000..d1f8ce3
>>>>>>> --- /dev/null
>>>>>>> +++ b/docs/generic-loader.txt
>>>>>>> @@ -0,0 +1,81 @@
>>>>>>> +Copyright (c) 2016 Xilinx Inc.
>>>>>>> +
>>>>>>> +This work is licensed under the terms of the GNU GPL, version 2 or later.  See
>>>>>>> +the COPYING file in the top-level directory.
>>>>>>> +
>>>>>>> +
>>>>>>> +The 'loader' device allows the user to load multiple images or values into
>>>>>>> +QEMU at startup.
>>>>>>> +
>>>>>>> +Loading Data into Memory Values
>>>>>>> +---------------------
>>>>>>> +The loader device allows memory values to be set from the command line. This
>>>>>>> +can be done by following the syntax below:
>>>>>>> +
>>>>>>> +     -device loader,addr=<addr>,data=<data>,data-len=<data-len>
>>>>>>> +                   [,data-be=<data-be>][,cpu-num=<cpu-num>]
>>>>>>> +
>>>>>>> +    <addr>      - The address to store the data in.
>>>>>>> +    <data>      - The value to be written to the address. The maximum size of
>>>>>>> +                  the data is 8 bytes.
>>>>>>> +    <data-len>  - The length of the data in bytes. This argument must be
>>>>>>> +                  included if the data argument is.
>>>>>>> +    <data-be>   - Set to true if the data to be stored on the guest should be
>>>>>>> +                  written as big endian data. The default is to write little
>>>>>>> +                  endian data.
>>>>>>> +    <cpu-num>   - The number of the CPU's address space where the data should
>>>>>>> +                  be loaded. If not specified the address space of the first
>>>>>>> +                  CPU is used.
>>>>>>> +
>>>>>>> +For all values both hex and decimal values are allowed. By default the values
>>>>>>> +will be parsed as decimal. To use hex values the user should prefix the number
>>>>>>> +with a '0x'.
>>>>>>
>>>>>> Unless you bypassed QemuOpts number parsing somehow, octal works as
>>>>>> well.  In case you did bypass: don't!  Command line consistency matters.
>>>>>> Follow-up patch reverting the bypass would be required.
>>>>>>
>>>>>> Not sure we want to document QemuOpts number syntax everywhere we
>>>>>> explain how a certain feature uses the command line.  A pointer to the
>>>>>> canonical place could be better.  Anyway, not something that needs
>>>>>> fixing before we commit.
>>>>>
>>>>> I didn't bypass it, octal should work as well. I have clarified that a
>>>>> bit in the doc.
>>>>
>>>> Thanks.
>>>>
>>>>>>> +
>>>>>>> +An example of loading value 0x8000000e to address 0xfd1a0104 is:
>>>>>>> +    -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4
>>>>>>> +
>>>>>>> +Setting a CPU's Program Counter
>>>>>>> +---------------------
>>>>>>> +The loader device allows the CPU's PC to be set from the command line. This
>>>>>>> +can be done by following the syntax below:
>>>>>>> +
>>>>>>> +     -device loader,addr=<addr>,cpu-num=<cpu-num>
>>>>>>> +
>>>>>>> +    <addr>      - The value to use as the CPU's PC.
>>>>>>> +    <cpu-num>   - The number of the CPU whose PC should be set to the
>>>>>>> +                  specified value.
>>>>>>> +
>>>>>>> +For all values both hex and decimal values are allowed. By default the values
>>>>>>> +will be parsed as decimal. To use hex values the user should prefix the number
>>>>>>> +with a '0x'.
>>>>>>> +
>>>>>>> +An example of setting CPU 0's PC to 0x8000 is:
>>>>>>> +    -device loader,addr=0x8000,cpu-num=0
>>>>>>> +
>>>>>>> +Loading Files
>>>>>>> +---------------------
>>>>>>> +The loader device also allows files to be loaded into memory. This can be done
>>>>>>> +similarly to setting memory values. The syntax is shown below:
>>>>>>> +
>>>>>>> +    -device loader,file=<file>[,addr=<addr>][,cpu-num=<cpu-num>][,force-raw=<raw>]
>>>>>>> +
>>>>>>> +    <file>      - A file to be loaded into memory
>>>>>>> +    <addr>      - The addr in memory that the file should be loaded. This is
>>>>>>> +                  ignored if you are using an ELF (unless force-raw is true).
>>>>>>> +                  This is required if you aren't loading an ELF.
>>>>>>> +    <cpu-num>   - This specifies the CPU that should be used. This is an
>>>>>>> +                  optional argument and will cause the CPU's PC to be set to
>>>>>>> +                  where the image is stored or in the case of an ELF file to
>>>>>>> +                  the value in the header. This option should only be used
>>>>>>> +                  for the boot image.
>>>>>>> +                  This will also cause the image to be written to the specified
>>>>>>> +                  CPU's address space. If not specified, the default is CPU 0.
>>>>>>
>>>>>> Using @cpu-num both for further specifying the meaning of @addr and for
>>>>>> setting that CPU's PC is awkward.  Are you sure there will never be a
>>>>>> use case where you need to specify the CPU without also setting its PC?
>>>>>>
>>>>>> To be clear: while I feel this is a question we must discuss and
>>>>>> resolve, I don't think we need to hold the series for it.
>>>>>
>>>>> I agree that this can occur. Internally in the loader framework is a
>>>>> set_pc variable.
>>>>>
>>>>> In the future we can make this user accessible and then allow that to
>>>>> decide if the PC should be set or not.
>>>>
>>>> If you can't do it right away, please document it as restriction, and
>>>> add a TODO comment to lift it.
>>>
>>> I have a patch that adds known restrictions.
>>>
>>>>
>>>>>>> +    <force-raw> - Forces the file to be treated as a raw image. This can be
>>>>>>> +                  used to specify the load address of ELF files.
>>>>>>
>>>>>> "Specifying the load address of an ELF file" sounds like loading a
>>>>>> position-independent ELF file at a particular address.  But I guess this
>>>>>> is actually for loading a file raw even though it is recognized by QEMU
>>>>>> as ELF.
>>>>>
>>>>> This option basically does make an ELF file position-independent as
>>>>> the user can control where it is loaded.
>>>>
>>>> Aha.  Then the name "force-raw" is confusing.
>>>
>>> I disagree. It tells QEMU to treat the image as just a dumb blob,
>>> instead of loading it as and ELF file. I thin force-raw makes sense as
>>> the user is telling QEMU that the image should be treated as a raw
>>> image, no matter what it actually is.
>>
>> I'm still confused then.
>>
>> I can see two possible features here, and based on your documentation
>> and commentary, I can't tell which one you implemented:
>>
>> 0. QEMU can load raw files and ELF executable files.  Raw files are
>> loaded verbatim at a the specified address.  ELF executable files are
>> loaded by an ELF loader, which loads the program header table's loadable
>> segments.
>>
>> 1. force-raw overrides the ELF detection, to let you load an ELF
>> executable file verbatim, as if it was raw.
>
> This is what the option does. It forces the image to be treated as a raw image.

Okay, makes sense now.

> I'm sorry if I implied it was option 2 instead.

No problem.  Suggest to clarify docs/generic-loader.txt, perhaps like
this:

    Loading Files
    -------------

    The loader device also allows files to be loaded into memory.  It
    can load raw files and ELF executable files.  Raw files are loaded
    verbatim.  ELF executable files are loaded by an ELF loader.  The
    syntax is shown below:

[...]
        <force-raw> - force-raw=on forces the file to be treated as a raw
                      image.  This can be used to load ELF files as if
                      they were raw.

Re: [Qemu-devel] [PATCH v12 2/2] docs: Add a generic loader explanation document

[Alistair Francis]

On Wed, Oct 5, 2016 at 12:44 AM, Markus Armbruster <armbru@redhat.com> wrote:
> Alistair Francis <alistair.francis@xilinx.com> writes:
>
>> On Tue, Oct 4, 2016 at 12:56 AM, Markus Armbruster <armbru@redhat.com> wrote:
>>> Alistair Francis <alistair.francis@xilinx.com> writes:
>>>
>>>> On Thu, Sep 29, 2016 at 10:36 PM, Markus Armbruster <armbru@redhat.com> wrote:
>>>>> Alistair Francis <alistair.francis@xilinx.com> writes:
>>>>>
>>>>>> On Thu, Sep 29, 2016 at 2:24 AM, Markus Armbruster <armbru@redhat.com> wrote:
>>>>>>> Alistair Francis <alistair.francis@xilinx.com> writes:
>>>>>>>
>>>>>>>> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
>>>>>>>> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
>>>>>>>> ---
>>>>>>>> V11:
>>>>>>>>  - Fix corrections
>>>>>>>> V10:
>>>>>>>>  - Split the data loading and PC setting
>>>>>>>> V9:
>>>>>>>>  - Clarify the image loading options
>>>>>>>> V8:
>>>>>>>>  - Improve documentation
>>>>>>>> V6:
>>>>>>>>  - Fixup documentation
>>>>>>>> V4:
>>>>>>>>  - Re-write to be more comprehensive
>>>>>>>>
>>>>>>>>  docs/generic-loader.txt | 81 +++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>>>  1 file changed, 81 insertions(+)
>>>>>>>>  create mode 100644 docs/generic-loader.txt
>>>>>>>>
>>>>>>>> diff --git a/docs/generic-loader.txt b/docs/generic-loader.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000..d1f8ce3
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/docs/generic-loader.txt
>>>>>>>> @@ -0,0 +1,81 @@
>>>>>>>> +Copyright (c) 2016 Xilinx Inc.
>>>>>>>> +
>>>>>>>> +This work is licensed under the terms of the GNU GPL, version 2 or later.  See
>>>>>>>> +the COPYING file in the top-level directory.
>>>>>>>> +
>>>>>>>> +
>>>>>>>> +The 'loader' device allows the user to load multiple images or values into
>>>>>>>> +QEMU at startup.
>>>>>>>> +
>>>>>>>> +Loading Data into Memory Values
>>>>>>>> +---------------------
>>>>>>>> +The loader device allows memory values to be set from the command line. This
>>>>>>>> +can be done by following the syntax below:
>>>>>>>> +
>>>>>>>> +     -device loader,addr=<addr>,data=<data>,data-len=<data-len>
>>>>>>>> +                   [,data-be=<data-be>][,cpu-num=<cpu-num>]
>>>>>>>> +
>>>>>>>> +    <addr>      - The address to store the data in.
>>>>>>>> +    <data>      - The value to be written to the address. The maximum size of
>>>>>>>> +                  the data is 8 bytes.
>>>>>>>> +    <data-len>  - The length of the data in bytes. This argument must be
>>>>>>>> +                  included if the data argument is.
>>>>>>>> +    <data-be>   - Set to true if the data to be stored on the guest should be
>>>>>>>> +                  written as big endian data. The default is to write little
>>>>>>>> +                  endian data.
>>>>>>>> +    <cpu-num>   - The number of the CPU's address space where the data should
>>>>>>>> +                  be loaded. If not specified the address space of the first
>>>>>>>> +                  CPU is used.
>>>>>>>> +
>>>>>>>> +For all values both hex and decimal values are allowed. By default the values
>>>>>>>> +will be parsed as decimal. To use hex values the user should prefix the number
>>>>>>>> +with a '0x'.
>>>>>>>
>>>>>>> Unless you bypassed QemuOpts number parsing somehow, octal works as
>>>>>>> well.  In case you did bypass: don't!  Command line consistency matters.
>>>>>>> Follow-up patch reverting the bypass would be required.
>>>>>>>
>>>>>>> Not sure we want to document QemuOpts number syntax everywhere we
>>>>>>> explain how a certain feature uses the command line.  A pointer to the
>>>>>>> canonical place could be better.  Anyway, not something that needs
>>>>>>> fixing before we commit.
>>>>>>
>>>>>> I didn't bypass it, octal should work as well. I have clarified that a
>>>>>> bit in the doc.
>>>>>
>>>>> Thanks.
>>>>>
>>>>>>>> +
>>>>>>>> +An example of loading value 0x8000000e to address 0xfd1a0104 is:
>>>>>>>> +    -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4
>>>>>>>> +
>>>>>>>> +Setting a CPU's Program Counter
>>>>>>>> +---------------------
>>>>>>>> +The loader device allows the CPU's PC to be set from the command line. This
>>>>>>>> +can be done by following the syntax below:
>>>>>>>> +
>>>>>>>> +     -device loader,addr=<addr>,cpu-num=<cpu-num>
>>>>>>>> +
>>>>>>>> +    <addr>      - The value to use as the CPU's PC.
>>>>>>>> +    <cpu-num>   - The number of the CPU whose PC should be set to the
>>>>>>>> +                  specified value.
>>>>>>>> +
>>>>>>>> +For all values both hex and decimal values are allowed. By default the values
>>>>>>>> +will be parsed as decimal. To use hex values the user should prefix the number
>>>>>>>> +with a '0x'.
>>>>>>>> +
>>>>>>>> +An example of setting CPU 0's PC to 0x8000 is:
>>>>>>>> +    -device loader,addr=0x8000,cpu-num=0
>>>>>>>> +
>>>>>>>> +Loading Files
>>>>>>>> +---------------------
>>>>>>>> +The loader device also allows files to be loaded into memory. This can be done
>>>>>>>> +similarly to setting memory values. The syntax is shown below:
>>>>>>>> +
>>>>>>>> +    -device loader,file=<file>[,addr=<addr>][,cpu-num=<cpu-num>][,force-raw=<raw>]
>>>>>>>> +
>>>>>>>> +    <file>      - A file to be loaded into memory
>>>>>>>> +    <addr>      - The addr in memory that the file should be loaded. This is
>>>>>>>> +                  ignored if you are using an ELF (unless force-raw is true).
>>>>>>>> +                  This is required if you aren't loading an ELF.
>>>>>>>> +    <cpu-num>   - This specifies the CPU that should be used. This is an
>>>>>>>> +                  optional argument and will cause the CPU's PC to be set to
>>>>>>>> +                  where the image is stored or in the case of an ELF file to
>>>>>>>> +                  the value in the header. This option should only be used
>>>>>>>> +                  for the boot image.
>>>>>>>> +                  This will also cause the image to be written to the specified
>>>>>>>> +                  CPU's address space. If not specified, the default is CPU 0.
>>>>>>>
>>>>>>> Using @cpu-num both for further specifying the meaning of @addr and for
>>>>>>> setting that CPU's PC is awkward.  Are you sure there will never be a
>>>>>>> use case where you need to specify the CPU without also setting its PC?
>>>>>>>
>>>>>>> To be clear: while I feel this is a question we must discuss and
>>>>>>> resolve, I don't think we need to hold the series for it.
>>>>>>
>>>>>> I agree that this can occur. Internally in the loader framework is a
>>>>>> set_pc variable.
>>>>>>
>>>>>> In the future we can make this user accessible and then allow that to
>>>>>> decide if the PC should be set or not.
>>>>>
>>>>> If you can't do it right away, please document it as restriction, and
>>>>> add a TODO comment to lift it.
>>>>
>>>> I have a patch that adds known restrictions.
>>>>
>>>>>
>>>>>>>> +    <force-raw> - Forces the file to be treated as a raw image. This can be
>>>>>>>> +                  used to specify the load address of ELF files.
>>>>>>>
>>>>>>> "Specifying the load address of an ELF file" sounds like loading a
>>>>>>> position-independent ELF file at a particular address.  But I guess this
>>>>>>> is actually for loading a file raw even though it is recognized by QEMU
>>>>>>> as ELF.
>>>>>>
>>>>>> This option basically does make an ELF file position-independent as
>>>>>> the user can control where it is loaded.
>>>>>
>>>>> Aha.  Then the name "force-raw" is confusing.
>>>>
>>>> I disagree. It tells QEMU to treat the image as just a dumb blob,
>>>> instead of loading it as and ELF file. I thin force-raw makes sense as
>>>> the user is telling QEMU that the image should be treated as a raw
>>>> image, no matter what it actually is.
>>>
>>> I'm still confused then.
>>>
>>> I can see two possible features here, and based on your documentation
>>> and commentary, I can't tell which one you implemented:
>>>
>>> 0. QEMU can load raw files and ELF executable files.  Raw files are
>>> loaded verbatim at a the specified address.  ELF executable files are
>>> loaded by an ELF loader, which loads the program header table's loadable
>>> segments.
>>>
>>> 1. force-raw overrides the ELF detection, to let you load an ELF
>>> executable file verbatim, as if it was raw.
>>
>> This is what the option does. It forces the image to be treated as a raw image.
>
> Okay, makes sense now.
>
>> I'm sorry if I implied it was option 2 instead.
>
> No problem.  Suggest to clarify docs/generic-loader.txt, perhaps like
> this:

Too easy. I sent a V3 of my docs updating patch which fixes this.

It's called: docs/generic-loader: Update the document

Thanks,

Alistair

>
>     Loading Files
>     -------------
>
>     The loader device also allows files to be loaded into memory.  It
>     can load raw files and ELF executable files.  Raw files are loaded
>     verbatim.  ELF executable files are loaded by an ELF loader.  The
>     syntax is shown below:
>
> [...]
>         <force-raw> - force-raw=on forces the file to be treated as a raw
>                       image.  This can be used to load ELF files as if
>                       they were raw.
>