Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader

[Alistair Francis]

On Tue, Sep 27, 2016 at 7:04 PM, Markus Armbruster  wrote:
> Alistair Francis  writes:
>
>> On Tue, Sep 27, 2016 at 8:40 AM, Markus Armbruster  wrote:
>>> Paolo Bonzini  writes:
>>>
 It does whatever cpu_physical_memory_write_rom (and hence
 cpu_memory_rw_debug, which has more callers) do.

> What happens when you try to monkey-patch and address that isn't
> connected to anything?

 /dev/null

> What happens when you try to monkey-patch some device's ROM?

 Overwritten.

> Memory-mapped I/O?

 Ignored.

> What happens when you monkey-patch persistent memory, such as pflash
> backed by a block backend?

 Overwritten (but not flushed).

> What happens if the address range crosses device boundaries?

 Writes over each area separately.
>>>
>>> Rejecting the ones that don't actually load stuff would be nice, but not
>>> a condition for merging this.
>>>
> >> If we decide to use this argument for the present interface design, I
> >> want it recorded in the code and commit messages.
>
> Fair request, don't you think?

 Yes, of course.
>>>
>>> Okay, looking forward to these improvements.
>>
>> Ok, so does this mean with the correct justification that Markus
>> mentions above this is fine to keep using -device?
>
> Yes, I've convinced myself that -device is no worse than -object.  All
> I'm asking for is to record the argument for -device properly.
>
> It took me a while to arrive at this conclusion.  If you'd like to
> retrace my steps, look for "An argument for using -device could go as
> follows" in Message-ID: <87ponvxcit@dusky.pond.sub.org>.
>
>> The justification is along the lines of the backend required is so
>> trivial that we just merged it in with the frontend.
>
> Two points: one, why is this a device, and two, why isn't it a split
> device.  Point one is more important.  The argument I could by there:
> it's a thoroughly weird device that provides no hardware interface of
> its own, but instead monkey patches memory provided by something else
> (devices or the board).

Sounds fair. I'm resending my last two patches now with an updated
commit message.

Thanks,

Alistair

>

Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader

[Markus Armbruster]

Alistair Francis  writes:

> On Tue, Sep 27, 2016 at 8:40 AM, Markus Armbruster  wrote:
>> Paolo Bonzini  writes:
>>
>>> It does whatever cpu_physical_memory_write_rom (and hence
>>> cpu_memory_rw_debug, which has more callers) do.
>>>
 What happens when you try to monkey-patch and address that isn't
 connected to anything?
>>>
>>> /dev/null
>>>
 What happens when you try to monkey-patch some device's ROM?
>>>
>>> Overwritten.
>>>
 Memory-mapped I/O?
>>>
>>> Ignored.
>>>
 What happens when you monkey-patch persistent memory, such as pflash
 backed by a block backend?
>>>
>>> Overwritten (but not flushed).
>>>
 What happens if the address range crosses device boundaries?
>>>
>>> Writes over each area separately.
>>
>> Rejecting the ones that don't actually load stuff would be nice, but not
>> a condition for merging this.
>>
 >> If we decide to use this argument for the present interface design, I
 >> want it recorded in the code and commit messages.

 Fair request, don't you think?
>>>
>>> Yes, of course.
>>
>> Okay, looking forward to these improvements.
>
> Ok, so does this mean with the correct justification that Markus
> mentions above this is fine to keep using -device?

Yes, I've convinced myself that -device is no worse than -object.  All
I'm asking for is to record the argument for -device properly.

It took me a while to arrive at this conclusion.  If you'd like to
retrace my steps, look for "An argument for using -device could go as
follows" in Message-ID: <87ponvxcit@dusky.pond.sub.org>.

> The justification is along the lines of the backend required is so
> trivial that we just merged it in with the frontend.

Two points: one, why is this a device, and two, why isn't it a split
device.  Point one is more important.  The argument I could by there:
it's a thoroughly weird device that provides no hardware interface of
its own, but instead monkey patches memory provided by something else
(devices or the board).

Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader

[Alistair Francis]

On Tue, Sep 27, 2016 at 8:40 AM, Markus Armbruster  wrote:
> Paolo Bonzini  writes:
>
>> It does whatever cpu_physical_memory_write_rom (and hence
>> cpu_memory_rw_debug, which has more callers) do.
>>
>>> What happens when you try to monkey-patch and address that isn't
>>> connected to anything?
>>
>> /dev/null
>>
>>> What happens when you try to monkey-patch some device's ROM?
>>
>> Overwritten.
>>
>>> Memory-mapped I/O?
>>
>> Ignored.
>>
>>> What happens when you monkey-patch persistent memory, such as pflash
>>> backed by a block backend?
>>
>> Overwritten (but not flushed).
>>
>>> What happens if the address range crosses device boundaries?
>>
>> Writes over each area separately.
>
> Rejecting the ones that don't actually load stuff would be nice, but not
> a condition for merging this.
>
>>> >> If we decide to use this argument for the present interface design, I
>>> >> want it recorded in the code and commit messages.
>>>
>>> Fair request, don't you think?
>>
>> Yes, of course.
>
> Okay, looking forward to these improvements.

Ok, so does this mean with the correct justification that Markus
mentions above this is fine to keep using -device?
The justification is along the lines of the backend required is so
trivial that we just merged it in with the frontend.

Thanks,

Alistair

>
> Thanks!
>

Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader

[Markus Armbruster]

Paolo Bonzini  writes:

> It does whatever cpu_physical_memory_write_rom (and hence
> cpu_memory_rw_debug, which has more callers) do.
>
>> What happens when you try to monkey-patch and address that isn't
>> connected to anything?
>
> /dev/null
>
>> What happens when you try to monkey-patch some device's ROM?
>
> Overwritten.
>
>> Memory-mapped I/O?
>
> Ignored.
>
>> What happens when you monkey-patch persistent memory, such as pflash
>> backed by a block backend?
>
> Overwritten (but not flushed).
>
>> What happens if the address range crosses device boundaries?
>
> Writes over each area separately.

Rejecting the ones that don't actually load stuff would be nice, but not
a condition for merging this.

>> >> If we decide to use this argument for the present interface design, I
>> >> want it recorded in the code and commit messages.
>> 
>> Fair request, don't you think?
>
> Yes, of course.

Okay, looking forward to these improvements.

Thanks!

Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader

[Peter Maydell]

On 27 September 2016 at 06:28, Markus Armbruster  wrote:
> What happens when you try to monkey-patch and address that isn't
> connected to anything?
>
> What happens when you try to monkey-patch some device's ROM?
> Memory-mapped I/O?
>
> What happens when you monkey-patch persistent memory, such as pflash
> backed by a block backend?
>
> What happens if the address range crosses device boundaries?

These all come under the heading of "don't do that", the same
way it's a bad idea to tell QEMU to load an elf file via
-kernel which is set up to load to something other than RAM.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader

[Paolo Bonzini]

It does whatever cpu_physical_memory_write_rom (and hence
cpu_memory_rw_debug, which has more callers) do.

> What happens when you try to monkey-patch and address that isn't
> connected to anything?

/dev/null

> What happens when you try to monkey-patch some device's ROM?

Overwritten.

> Memory-mapped I/O?

Ignored.

> What happens when you monkey-patch persistent memory, such as pflash
> backed by a block backend?

Overwritten (but not flushed).

> What happens if the address range crosses device boundaries?

Writes over each area separately.

> >> If we decide to use this argument for the present interface design, I
> >> want it recorded in the code and commit messages.
> 
> Fair request, don't you think?

Yes, of course.

Paolo

Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader

[Markus Armbruster]

Paolo Bonzini  writes:

> On 23/09/2016 10:10, Markus Armbruster wrote:
>> For me, the similarity (at the conceptual level) to the persistent
>> memory case is striking: in both cases, we need a backend to manage
>> memory contents.  The difference is that for persistent memory, changes
>> persist, while for the loader, they get reverted at reset.
>
> Not just that.  For persistent memory, there is a MemoryRegion
> corresponding to the memory _and_ an interface to manage it.
>
> For the loader the contents are copied every time from an out-of-band
> storage.
>
>> An argument for using -device could go as follows: this is a device to
>> monkey patch memory.  It needs a backend to manage the bits, just like
>> other memory-related devices do.  Since its backend is trivial, we
>> folded it in rather than make it a separate backend.
>
> The backend is not just trivial, it is _literally_ a 64-bit value...  I
> think "-object long,value=0x123456789abcdef0 is taking things a bit too far.

I agree the "monkey-patch a 64-bit value" is a case where folding the
trivial backend into the frontend is sensible.  The "monkey-patch with
the contents of an ELF or raw image file" case could perhaps be done as
a backend of its own, but I'm not opposed to folding it in.

I'm actually trying hard to find -device acceptable :)  It's a
thoroughly weird device, though.

The generic loader "device" is a device that monkey-patches memory[*]
provided by something else, whatever that something else may be.

For memory configured with -device dimm, it's the dimm qdev.

For memory set up by the board and configured with -m, -bios and so
forth, there is no qdev.

It could also be some device's memory-mapped I/O or ROM.

Begs a few questions.

What happens when you try to monkey-patch and address that isn't
connected to anything?

What happens when you try to monkey-patch some device's ROM?
Memory-mapped I/O?

What happens when you monkey-patch persistent memory, such as pflash
backed by a block backend?

What happens if the address range crosses device boundaries?

Would we do the loader this way if all memory was uniformly modelled as
a qdev?

> Paolo
>
>> If we decide to use this argument for the present interface design, I
>> want it recorded in the code and commit messages.

Fair request, don't you think?


[*] It can also monkey-patch a CPU's PC, i.e. monkey-patch yet another
kind of device, but I'm ignoring that here.

Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader

[Markus Armbruster]

Peter Maydell  writes:

> On 22 September 2016 at 12:50, Markus Armbruster  wrote:
>> However, in the case we're discussing, we're not doing that!  There is
>> no RAM device with a trivial backend folded in.  There's only a weird
>> pseudo-device that copies the contents of a file into memory, then sits
>> around doing absolutely nothing.
>
> It doesn't sit around doing entirely nothing, it sits around
> so that when the machine is reset it can do the copying again...

True :)

> In any case, I'm going to drop patches 7 and 8 from target-arm.next
> for the moment so we can come to a consensus about whether this
> should be -device or -object (and possibly respin the patch to
> use -object if we decide that; hopefully it should be simple...)
> I'll keep patches 1..6 in.

Okay, that gives us a bit of time to try to settle the "is this a
device?" question.  How can we best make progress there?

Progress from where?  Starting from a gut feeling that -device is wrong,
I've come to the conclusion that conceptually, this really isn't a
frontend (-device), but a backend of a split device.  Hard to see
because we traditionally don't model memory devices as device objects of
their own.  Except for more interesting ones: persisent memory such as
flash since forever (because we need a backend to persist it), using
block backends created with -drive, and hot-pluggable memory more
recently (because we need a frontend to plug and unplug), using memory
backends created with -object.

For me, the similarity (at the conceptual level) to the persistent
memory case is striking: in both cases, we need a backend to manage
memory contents.  The difference is that for persistent memory, changes
persist, while for the loader, they get reverted at reset.

At the implementation level, though, the two are sadly different: for
persistent memory, the backend manages just contents, and is oblivious
of where it is mapped.  The mapping is done by binding the backend to a
frontend.  The "generic loader" doesn't just manage contents, it also
monkey-patches arbitrary(?) memory.  Feels like a hack to me.  A useful
hack, given the ways we model memory.

The hack part is perhaps kind of, sort of, almost device-like.  An
argument for using -device could go as follows: this is a device to
monkey patch memory.  It needs a backend to manage the bits, just like
other memory-related devices do.  Since its backend is trivial, we
folded it in rather than make it a separate backend.

If we decide to use this argument for the present interface design, I
want it recorded in the code and commit messages.

If, on the other hand, you come around to prefer a -object interface, it
would be fair to tell me "you want -object, you code it up".

Hmm, we already have a backend managing bits from a file:
memory-backend-file.  Naive question: could a read-only
memory-backend-file serve as backend for the "loader" hack device?
Mind, I'm not suggesting this is what we should do, I'm only trying to
understand how the new folded-in backend is related to existing
backends.

Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader

[Paolo Bonzini]

On 23/09/2016 10:10, Markus Armbruster wrote:
> For me, the similarity (at the conceptual level) to the persistent
> memory case is striking: in both cases, we need a backend to manage
> memory contents.  The difference is that for persistent memory, changes
> persist, while for the loader, they get reverted at reset.

Not just that.  For persistent memory, there is a MemoryRegion
corresponding to the memory _and_ an interface to manage it.

For the loader the contents are copied every time from an out-of-band
storage.

> An argument for using -device could go as follows: this is a device to
> monkey patch memory.  It needs a backend to manage the bits, just like
> other memory-related devices do.  Since its backend is trivial, we
> folded it in rather than make it a separate backend.

The backend is not just trivial, it is _literally_ a 64-bit value...  I
think "-object long,value=0x123456789abcdef0 is taking things a bit too far.

Paolo

> If we decide to use this argument for the present interface design, I
> want it recorded in the code and commit messages.

Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader

[Peter Maydell]

On 22 September 2016 at 12:50, Markus Armbruster  wrote:
> However, in the case we're discussing, we're not doing that!  There is
> no RAM device with a trivial backend folded in.  There's only a weird
> pseudo-device that copies the contents of a file into memory, then sits
> around doing absolutely nothing.

It doesn't sit around doing entirely nothing, it sits around
so that when the machine is reset it can do the copying again...

In any case, I'm going to drop patches 7 and 8 from target-arm.next
for the moment so we can come to a consensus about whether this
should be -device or -object (and possibly respin the patch to
use -object if we decide that; hopefully it should be simple...)
I'll keep patches 1..6 in.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader

[Markus Armbruster]

Paolo Bonzini  writes:

> On 22/09/2016 11:19, Markus Armbruster wrote:
>>> > I think -device is okay for something that isn't a "backend" but is
>>> > directly guest-visible.
>> Well, the contents of a block device is just as guest-visible.  We split
>> the device in a frontend and a backend, and the contents comes from the
>> backend.
>> 
>> We traditionally don't model memory as a split device.  Perhaps we
>> should.  Regardless of whether we actually do, "contents of a memory
>> device that you need to create by some other means (explicit or
>> implicit)" feels much more like -object than like -device to me.
>
> The closest precedents here are "-bios" (not an object at all), PCI ROMs
> (a property points to the file), and "-pflash" (split into backend and
> frontend, the frontend being a device).

-pflash ARG is sugar for -drive if=pflash,file=ARG.  Like all -drive
other than drive if=none, it creates a block backend and asks the board
to create a block frontend.  Some boards create a modern QOMified device
such as "cfi.pflash01", some create just a ROM memory region, which
isn't a device (in the same way RAM normally isn't), and some ignore the
request silently.

The modern, fully general form for QOMified devices would be to define
the backend with -drive if=none, and the frontend with -device.

-bios ARG is sugar for -machine firmware=ARG.  This asks the board to
load firmware from file ARG.  Again, boards could create a modern
QOMified ROM device (theoretical, not sure there are any), a non-device
ROM memory region, or ignore the request.  The difference to pflash is
that we don't wrap a full-blown block backend around the file, simply
because that would complicate things for no gain.  But that's detail;
it's playing the role of a backend all the same.

A (QOMified) PCI may have a PCI ROM.  To configure its contents, you use
a PCI device property naming a file.

In all cases, QOMified devices get bits from the host via a backend.
The backend can be an explicit object (e.g. a block backend) or, if the
backend is trivial, folded into the frontend.

> I think there is a device concept in here, the question is whether you
> want to split the backend and frontend.  For read-only data the
> precedents favor not splitting it.

Yes, we sometimes choose to fold trivial backends into the frontends
instead of doing a split device.  That's fine.

However, in the case we're discussing, we're not doing that!  There is
no RAM device with a trivial backend folded in.  There's only a weird
pseudo-device that copies the contents of a file into memory, then sits
around doing absolutely nothing.

For me, that's an abuse of -device.  It's certainly no worse than some
other parts of the QEMU command line / QMP.  Not exactly a good excuse,
though :)

Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader

[Paolo Bonzini]

On 22/09/2016 11:19, Markus Armbruster wrote:
>> > I think -device is okay for something that isn't a "backend" but is
>> > directly guest-visible.
> Well, the contents of a block device is just as guest-visible.  We split
> the device in a frontend and a backend, and the contents comes from the
> backend.
> 
> We traditionally don't model memory as a split device.  Perhaps we
> should.  Regardless of whether we actually do, "contents of a memory
> device that you need to create by some other means (explicit or
> implicit)" feels much more like -object than like -device to me.

The closest precedents here are "-bios" (not an object at all), PCI ROMs
(a property points to the file), and "-pflash" (split into backend and
frontend, the frontend being a device).

I think there is a device concept in here, the question is whether you
want to split the backend and frontend.  For read-only data the
precedents favor not splitting it.

Paolo

Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader

[Markus Armbruster]

Paolo Bonzini  writes:

> On 21/09/2016 17:46, Alistair Francis wrote:
>>> > I know it's way too late for design questions, but the thought just
>>> > occured to me: -device gives you what you need without defining yet
>>> > another command line option (good!), but is it appropriate?  It's not
>>> > exactly a device...  Would -object be a better fit?  I honestly don't
>>> > know.  Paolo?
>> I see your point, but I kind of think it makes sense that everything
>> uses the same command line argument.
>> 
>> I image it would be very confusing if we have -device and -object.
>> Then when you want to add something you will need to figure out if it
>> is a device or an object? How do you know which one is which?
>> 
>> I agree that technically it isn't a device but I think this is still
>> clear what you are trying to do.
>
> I think -device is okay for something that isn't a "backend" but is
> directly guest-visible.

Well, the contents of a block device is just as guest-visible.  We split
the device in a frontend and a backend, and the contents comes from the
backend.

We traditionally don't model memory as a split device.  Perhaps we
should.  Regardless of whether we actually do, "contents of a memory
device that you need to create by some other means (explicit or
implicit)" feels much more like -object than like -device to me.

Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader

[Paolo Bonzini]

On 21/09/2016 17:46, Alistair Francis wrote:
>> > I know it's way too late for design questions, but the thought just
>> > occured to me: -device gives you what you need without defining yet
>> > another command line option (good!), but is it appropriate?  It's not
>> > exactly a device...  Would -object be a better fit?  I honestly don't
>> > know.  Paolo?
> I see your point, but I kind of think it makes sense that everything
> uses the same command line argument.
> 
> I image it would be very confusing if we have -device and -object.
> Then when you want to add something you will need to figure out if it
> is a device or an object? How do you know which one is which?
> 
> I agree that technically it isn't a device but I think this is still
> clear what you are trying to do.

I think -device is okay for something that isn't a "backend" but is
directly guest-visible.

Paolo

Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader

[Daniel P. Berrange]

On Wed, Sep 21, 2016 at 08:05:23AM +0200, Markus Armbruster wrote:
> Alistair Francis  writes:
> 
> > 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=0x800e,data-len=4
> >
> > Images can be loaded like this: -device 
> > loader,file=./images/u-boot.elf,cpu=0
> 
> I know it's way too late for design questions, but the thought just
> occured to me: -device gives you what you need without defining yet
> another command line option (good!), but is it appropriate?  It's not
> exactly a device...  Would -object be a better fit?  I honestly don't
> know.  Paolo?

Yes, -object would be better. Basically -device is used to create stuff
which is related to guest ABI, while -object is used to create anything
else, which is basically host integration stuff.

Loading firmeware images is clearly host integration, so belongs in
-object


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader

[Alistair Francis]

On Tue, Sep 20, 2016 at 11:05 PM, Markus Armbruster  wrote:
> Alistair Francis  writes:
>
>> 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=0x800e,data-len=4
>>
>> Images can be loaded like this: -device loader,file=./images/u-boot.elf,cpu=0
>
> I know it's way too late for design questions, but the thought just
> occured to me: -device gives you what you need without defining yet
> another command line option (good!), but is it appropriate?  It's not
> exactly a device...  Would -object be a better fit?  I honestly don't
> know.  Paolo?

I see your point, but I kind of think it makes sense that everything
uses the same command line argument.

I image it would be very confusing if we have -device and -object.
Then when you want to add something you will need to figure out if it
is a device or an object? How do you know which one is which?

I agree that technically it isn't a device but I think this is still
clear what you are trying to do.

Thanks,

Alistair

>
> If this question leads to changes, they can be done on top.
>
>> 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.
>

Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader

[Markus Armbruster]

Alistair Francis  writes:

> 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=0x800e,data-len=4
>
> Images can be loaded like this: -device loader,file=./images/u-boot.elf,cpu=0

I know it's way too late for design questions, but the thought just
occured to me: -device gives you what you need without defining yet
another command line option (good!), but is it appropriate?  It's not
exactly a device...  Would -object be a better fit?  I honestly don't
know.  Paolo?

If this question leads to changes, they can be done on top.

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

Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader

[Alistair Francis]

On Tue, Sep 20, 2016 at 10:41 AM, Peter Maydell
 wrote:
> On 20 September 2016 at 15:54, Alistair Francis
>  wrote:
>> 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=0x800e,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.
>
>
>
> Applied to target-arm.next, thanks.
>

Woo! Thanks Peter

Alistair

> -- PMM
>

Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader

[Peter Maydell]

On 20 September 2016 at 15:54, Alistair Francis
 wrote:
> 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=0x800e,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.



Applied to target-arm.next, thanks.

-- PMM