From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54445) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bp4ES-0002Cx-Qn for qemu-devel@nongnu.org; Tue, 27 Sep 2016 22:04:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bp4EP-0006KQ-FI for qemu-devel@nongnu.org; Tue, 27 Sep 2016 22:04:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59302) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bp4EP-0006J8-6i for qemu-devel@nongnu.org; Tue, 27 Sep 2016 22:04:21 -0400 From: Markus Armbruster References: <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> <87lgydii9w.fsf@dusky.pond.sub.org> <1764179128.3091209.1474985640517.JavaMail.zimbra@redhat.com> <874m51e4h6.fsf@dusky.pond.sub.org> Date: Wed, 28 Sep 2016 04:04:17 +0200 In-Reply-To: (Alistair Francis's message of "Tue, 27 Sep 2016 09:24:09 -0700") Message-ID: <87intg93vi.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: Alistair Francis Cc: Peter Maydell , "qemu-devel@nongnu.org Developers" , Peter Crosthwaite , Christopher Covington , Paolo Bonzini 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.fsf@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).