[Top][All Lists]

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

Re: [Qemu-arm] [RFC PATCH] exec: Support non-direct memory writes in cpu

From: Andrey Smirnov
Subject: Re: [Qemu-arm] [RFC PATCH] exec: Support non-direct memory writes in cpu_memory_rw_debug
Date: Thu, 30 Jun 2016 11:21:31 -0700

On Wed, Jun 29, 2016 at 8:55 AM, Paolo Bonzini <address@hidden> wrote:
> On 28/06/2016 23:44, Andrey Smirnov wrote:
>> Add code to support writing to memory mapped peripherals via
>> cpu_memory_rw_debug(). The code of that function already supports
>> reading from such memory regions, so this commit makes that
>> functionality "symmetric".
> It's not entirely symmetric however, as you cannot write to the MMIO
> registers of romd devices.  Is this correct?  So I'll leave to others
> the review of whether the functionality is appropriate.

What I meant by "symmetric" is that with that change address_space_rw
is used in both code-paths: for reading and for writing. As for your
question, I think so, the reason why I kept it that way was to
preserve the old code's behavior (see
cpu_physical_memory_write_rom_internal). However according to the
comments/documentation in memory.h writes to ROM devices in ROMD and
MMIO mode should always be handled via callbacks so there seem to be a
contradiction there. I don't know QEMU codebase well enough to make a
call on who's right, so I tried to keep the old behavior.

> Regarding the code:
>> @@ -2621,7 +2625,7 @@ static MemTxResult 
>> address_space_write_continue(AddressSpace *as, hwaddr addr,
>>  }
>>  MemTxResult address_space_write(AddressSpace *as, hwaddr addr, MemTxAttrs 
>> attrs,
>> -                                const uint8_t *buf, int len)
>> +                                const uint8_t *buf, int len, bool force)
> I would prefer to leave this API as is, and instead add a new API such
> as address_space_write_debug or address_space_program.  It's okay to add
> the "force" argument to address_space_write_continue.

Having thought about that, I agree. Will update in v2.


reply via email to

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