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
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)
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
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
On 27 September 2016 at 06:28, Markus Armbruster wrote:
> 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
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.
>
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
Peter Maydell writes:
> On 22 September 2016 at 12:50, Markus Armbruster wrote:
>> However, in the case we're discussing, we're not doing that! There is
>> no RAM device with a trivial backend folded in. There's only a weird
>> pseudo-device that
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
On 22 September 2016 at 12:50, Markus Armbruster wrote:
> However, in the case we're discussing, we're not doing that! There is
> no RAM device with a trivial backend folded in. There's only a weird
> pseudo-device that copies the contents of a file into memory, then sits
>
Paolo Bonzini writes:
> On 22/09/2016 11:19, Markus Armbruster wrote:
>>> > I think -device is okay for something that isn't a "backend" but is
>>> > directly guest-visible.
>> Well, the contents of a block device is just as guest-visible. We split
>> the device in a
On 22/09/2016 11:19, Markus Armbruster wrote:
>> > I think -device is okay for something that isn't a "backend" but is
>> > directly guest-visible.
> Well, the contents of a block device is just as guest-visible. We split
> the device in a frontend and a backend, and the contents comes from the
Paolo Bonzini writes:
> On 21/09/2016 17:46, Alistair Francis wrote:
>>> > I know it's way too late for design questions, but the thought just
>>> > occured to me: -device gives you what you need without defining yet
>>> > another command line option (good!), but is it
On 21/09/2016 17:46, Alistair Francis wrote:
>> > I know it's way too late for design questions, but the thought just
>> > occured to me: -device gives you what you need without defining yet
>> > another command line option (good!), but is it appropriate? It's not
>> > exactly a device...
On Wed, Sep 21, 2016 at 08:05:23AM +0200, Markus Armbruster wrote:
> Alistair Francis writes:
>
> > This work is based on the original work by Li Guang with extra
> > features added by Peter C and myself.
> >
> > The idea of this loader is to allow the user to load
On Tue, Sep 20, 2016 at 11:05 PM, Markus Armbruster wrote:
> Alistair Francis writes:
>
>> This work is based on the original work by Li Guang with extra
>> features added by Peter C and myself.
>>
>> The idea of this loader is to allow the user to
Alistair Francis writes:
> This work is based on the original work by Li Guang with extra
> features added by Peter C and myself.
>
> The idea of this loader is to allow the user to load multiple images
> or values into QEMU at startup.
>
> Memory values can be
On Tue, Sep 20, 2016 at 10:41 AM, Peter Maydell
wrote:
> On 20 September 2016 at 15:54, Alistair Francis
> wrote:
>> This work is based on the original work by Li Guang with extra
>> features added by Peter C and myself.
>>
>> The idea of
On 20 September 2016 at 15:54, Alistair Francis
wrote:
> This work is based on the original work by Li Guang with extra
> features added by Peter C and myself.
>
> The idea of this loader is to allow the user to load multiple images
> or values into QEMU at startup.
>
This work is based on the original work by Li Guang with extra
features added by Peter C and myself.
The idea of this loader is to allow the user to load multiple images
or values into QEMU at startup.
Memory values can be loaded like this: -device
20 matches
Mail list logo