From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39239) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpNfI-0000dO-6f for qemu-devel@nongnu.org; Wed, 28 Sep 2016 18:49:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bpNfF-0003gK-TA for qemu-devel@nongnu.org; Wed, 28 Sep 2016 18:49:23 -0400 Received: from mail-oi0-x241.google.com ([2607:f8b0:4003:c06::241]:33626) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpNfF-0003gA-O5 for qemu-devel@nongnu.org; Wed, 28 Sep 2016 18:49:21 -0400 Received: by mail-oi0-x241.google.com with SMTP id w11so3944502oia.0 for ; Wed, 28 Sep 2016 15:49:21 -0700 (PDT) MIME-Version: 1.0 Sender: alistair23@gmail.com In-Reply-To: <87intg93vi.fsf@dusky.pond.sub.org> 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> <87intg93vi.fsf@dusky.pond.sub.org> From: Alistair Francis Date: Wed, 28 Sep 2016 15:48:50 -0700 Message-ID: Content-Type: text/plain; charset=UTF-8 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: Markus Armbruster Cc: Alistair Francis , Peter Maydell , Peter Crosthwaite , Paolo Bonzini , "qemu-devel@nongnu.org Developers" , Christopher Covington 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.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). Sounds fair. I'm resending my last two patches now with an updated commit message. Thanks, Alistair >