From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:53324)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <alistair23@gmail.com>) id 1br73Q-0000cL-R1
	for qemu-devel@nongnu.org; Mon, 03 Oct 2016 13:29:30 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <alistair23@gmail.com>) id 1br73P-0000n8-3t
	for qemu-devel@nongnu.org; Mon, 03 Oct 2016 13:29:28 -0400
Received: from mail-oi0-x243.google.com ([2607:f8b0:4003:c06::243]:35344)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <alistair23@gmail.com>) id 1br73O-0000mW-Tq
	for qemu-devel@nongnu.org; Mon, 03 Oct 2016 13:29:27 -0400
Received: by mail-oi0-x243.google.com with SMTP id n202so12149335oig.2
	for <qemu-devel@nongnu.org>; Mon, 03 Oct 2016 10:29:26 -0700 (PDT)
MIME-Version: 1.0
Sender: alistair23@gmail.com
In-Reply-To: <874m4yx82t.fsf@dusky.pond.sub.org>
References: <cover.1475102513.git.alistair.francis@xilinx.com>
	<0c4600f5c922569a57f4e9a9f1b6b4b5469b2a4c.1475102513.git.alistair.francis@xilinx.com>
	<871t03jbxh.fsf@dusky.pond.sub.org>
	<CAKmqyKPQDrpe57MP0gkn8M3gOjhamzzJi7+b+8qoSRpbRn8q2g@mail.gmail.com>
	<874m4yx82t.fsf@dusky.pond.sub.org>
From: Alistair Francis <alistair.francis@xilinx.com>
Date: Mon, 3 Oct 2016 10:28:55 -0700
Message-ID: <CAKmqyKP+sEG-rUgLD5SWXVB=WQ0xAhqBNU8buecqDXdoM6rh2g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [Qemu-devel] [PATCH v12 2/2] docs: Add a generic loader
 explanation document
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Markus Armbruster <armbru@redhat.com>
Cc: Alistair Francis <alistair.francis@xilinx.com>, Peter Maydell <peter.maydell@linaro.org>, Peter Crosthwaite <crosthwaitepeter@gmail.com>, Paolo Bonzini <pbonzini@redhat.com>, "qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>, Christopher Covington <cov@codeaurora.org>

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.
>>>
>