From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56712) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bosQz-0002S2-RI for qemu-devel@nongnu.org; Tue, 27 Sep 2016 09:28:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bosQy-0000FG-F4 for qemu-devel@nongnu.org; Tue, 27 Sep 2016 09:28:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bosQy-0000Eb-5H for qemu-devel@nongnu.org; Tue, 27 Sep 2016 09:28:32 -0400 From: Markus Armbruster References: <877fa5aiu4.fsf@dusky.pond.sub.org> <6373e011-5068-b0ae-5672-e3704af556d9@redhat.com> <87h998nvf6.fsf@dusky.pond.sub.org> <6280ba63-cbe9-c2d3-ba8f-7de1369f059e@redhat.com> <87vaxojgqw.fsf@dusky.pond.sub.org> <87ponvxcit.fsf@dusky.pond.sub.org> <7046636c-a89b-2991-083f-bf73bb29f070@redhat.com> Date: Tue, 27 Sep 2016 15:28:27 +0200 In-Reply-To: <7046636c-a89b-2991-083f-bf73bb29f070@redhat.com> (Paolo Bonzini's message of "Fri, 23 Sep 2016 10:18:04 +0200") Message-ID: <87lgydii9w.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Maydell , "qemu-devel@nongnu.org Developers" , Peter Crosthwaite , Christopher Covington , Alistair Francis 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.