From: Markus Armbruster <armbru@redhat.com>
To: Alistair Francis <alistair.francis@xilinx.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
Peter Crosthwaite <crosthwaitepeter@gmail.com>,
Christopher Covington <cov@codeaurora.org>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader
Date: Wed, 28 Sep 2016 04:04:17 +0200 [thread overview]
Message-ID: <87intg93vi.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <CAKmqyKOqTvB3TncBpDuKYVZr=6XSAWEwn70e_R5jFSFZygfXbw@mail.gmail.com> (Alistair Francis's message of "Tue, 27 Sep 2016 09:24:09 -0700")
Alistair Francis <alistair.francis@xilinx.com> writes:
> On Tue, Sep 27, 2016 at 8:40 AM, Markus Armbruster <armbru@redhat.com> wrote:
>> Paolo Bonzini <pbonzini@redhat.com> 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).
next prev parent reply other threads:[~2016-09-28 2:04 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-20 14:54 [Qemu-devel] [PATCH v11 0/8] Add a generic loader Alistair Francis
2016-09-20 14:54 ` [Qemu-devel] [PATCH v11 1/8] loader: Allow ELF loader to auto-detect the ELF arch Alistair Francis
2016-09-20 14:54 ` [Qemu-devel] [PATCH v11 2/8] loader: Use the specified MemoryRegion Alistair Francis
2016-09-20 14:54 ` [Qemu-devel] [PATCH v11 3/8] loader: Allow a custom AddressSpace when loading ROMs Alistair Francis
2016-09-20 14:54 ` [Qemu-devel] [PATCH v11 4/8] loader: Add AddressSpace loading support to ELFs Alistair Francis
2016-09-20 14:54 ` [Qemu-devel] [PATCH v11 5/8] loader: Add AddressSpace loading support to uImages Alistair Francis
2016-09-20 14:54 ` [Qemu-devel] [PATCH v11 6/8] loader: Add AddressSpace loading support to targphys Alistair Francis
2016-09-20 14:54 ` [Qemu-devel] [PATCH v11 7/8] generic-loader: Add a generic loader Alistair Francis
2016-09-20 14:54 ` [Qemu-devel] [PATCH v11 8/8] docs: Add a generic loader explanation document Alistair Francis
2016-09-20 17:41 ` [Qemu-devel] [PATCH v11 0/8] Add a generic loader Peter Maydell
2016-09-20 18:22 ` Alistair Francis
2016-09-21 6:05 ` Markus Armbruster
2016-09-21 15:46 ` Alistair Francis
2016-09-21 15:53 ` Paolo Bonzini
2016-09-22 9:19 ` Markus Armbruster
2016-09-22 9:22 ` Paolo Bonzini
2016-09-22 11:50 ` Markus Armbruster
2016-09-22 14:01 ` Peter Maydell
2016-09-23 8:10 ` Markus Armbruster
2016-09-23 8:18 ` Paolo Bonzini
2016-09-27 13:28 ` Markus Armbruster
2016-09-27 14:14 ` Paolo Bonzini
2016-09-27 15:40 ` Markus Armbruster
2016-09-27 16:24 ` Alistair Francis
2016-09-28 2:04 ` Markus Armbruster [this message]
2016-09-28 22:48 ` Alistair Francis
2016-09-27 15:17 ` Peter Maydell
2016-09-21 15:54 ` Daniel P. Berrange
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87intg93vi.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=alistair.francis@xilinx.com \
--cc=cov@codeaurora.org \
--cc=crosthwaitepeter@gmail.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.