qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/5] address_space: replaced function calls


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 1/5] address_space: replaced function calls
Date: Sun, 13 Mar 2016 19:10:29 +0000

On 13 March 2016 at 18:56, Mriyam Tamuli <address@hidden> wrote:
> replaced calls named cpu_physical_memory_* with address_space_*
>
> cpus.c
> cputlb.c
> disas.c
> exec.c
> ---
>  cpus.c   |  2 +-
>  cputlb.c |  8 ++++----
>  disas.c  |  2 +-
>  exec.c   | 60 ++++++++++++++++++++++++++++++------------------------------
>  4 files changed, 36 insertions(+), 36 deletions(-)
>
> diff --git a/cpus.c b/cpus.c
> index bc774e2..d73cd7b 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -1662,7 +1662,7 @@ void qmp_pmemsave(int64_t addr, int64_t size, const 
> char *filename,
>          l = sizeof(buf);
>          if (l > size)
>              l = size;
> -        cpu_physical_memory_read(addr, buf, l);
> +        address_space_read(addr, buf, l);

address_space_read() takes five arguments, not three -- surely
this change won't compile?

> --- a/exec.c
> +++ b/exec.c
> @@ -991,9 +991,9 @@ static void tlb_reset_dirty_range_all(ram_addr_t start, 
> ram_addr_t length)
>  }
>
>  /* Note: start and end must be within the same ram block.  */
> -bool cpu_physical_memory_test_and_clear_dirty(ram_addr_t start,
> -                                              ram_addr_t length,
> -                                              unsigned client)
> +bool address_space_test_and_clear_dirty(ram_addr_t start,
> +                                        ram_addr_t length,
> +                                        unsigned client)

This doesn't look right either -- a function address_space_*
should take an AddressSpace* as argument.

The idea of the item on the BiteSizedTasks list is to
convert code (and in particular device model code) which uses
cpu_physical_memory_read() or cpu_physical_memory_write() from
using those functions (which implicitly act on the CPU's
default address space) to instead use functions which specify
their address space explicitly. This might involve changing
the devices to allow board code to pass the device a memory
region that it should use for DMA type accesses. In any case
it is not as simple as a pure search and replace operation.

thanks
-- PMM



reply via email to

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