qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader
Date: Wed, 28 Sep 2016 04:04:17 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Alistair Francis <address@hidden> writes:

> On Tue, Sep 27, 2016 at 8:40 AM, Markus Armbruster <address@hidden> wrote:
>> Paolo Bonzini <address@hidden> 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: <address@hidden>.

> 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).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]