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

[Markus Armbruster]

Paolo Bonzini <address@hidden> 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.