Paolo Bonzini <[email protected]> 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.
