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 <address@hidden> wrote:
> Alistair Francis <address@hidden> writes:
>
>> Signed-off-by: Alistair Francis <address@hidden>
>> Reviewed-by: Peter Maydell <address@hidden>
>> ---
>> 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.
>