qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] RFC: memory API changes


From: Peter Maydell
Subject: [Qemu-devel] RFC: memory API changes
Date: Mon, 23 Mar 2015 12:24:42 +0000

(This is part of the work I'm doing for transaction attributes.)

Currently we have several APIs used for making physical
memory accesses:

1. cpu_physical_memory_rw &c

2. address_space_rw/read/write/map

3. ld/st*_phys

These do more-or-less overlapping jobs and it's not
obvious which should be used when. Also they need to be
expanded to support transaction attributes and (in some
cases) reporting of failed memory transactions. I propose:

 * ld/st*_phys to be renamed to as_ld*, eg
    ldub_phys -> as_ldub
    ldl_be_phys -> as_ldl_be
    stq_phys -> as_stq
    stl_le_phys -> as_ldl_le
   and to take two new arguments:
    MemTxAttrs attrs, MemTxResult *result
   (existing callsites can pass MEMTXATTRS_UNSPECIFIED, NULL
   to get their current behaviour.)
 * address_space_rw &c to be renamed:
    address_space_rw -> as_rw_buf
    address_space_read -> as_read_buf
    address_space_write -> as_write_buf
    address_space_map -> as_map_buf &c
   This is just so the names line up nicely and we have a
   clear indication that this is a family of functions
 * address_space_read/write/rw should return MemTxResult rather
   than plain bool
 * we should put all the as_* function prototypes in one
   header, probably memory.h, rather than some in cpu-common.h
   and some in memory.h
 * cpu_physical_memory_rw are obsolete and should be replaced
   with uses of the as_* functions -- we should at least note
   this in the header file. (Can't do this as an automated change
   really because the correct AS to use is callsite dependent.)

I'm hoping I can use coccinelle to do the heavy lifting of
the renames. Before I make a start on that I wanted to see if
people agreed with this or had better naming suggestions.
as_* is a bit abbreviated but I felt that calling these
all address_space_lduw_le() and so on was a little unwieldy
(especially if compared to the lduw_le_phys names we have now).
Certainly we could do that if people prefer it, though.

The point of indicating failure via MemTxResult is that at
some point we need to correct the current broken handling of
the CPUClass do_unassigned_access hook, because that should
only be invoked if the CPU itself does an access to an unassigned
address, not if some random DMA'ing device does!

Comments appreciated; will try to produce actual patches this
week...

-- PMM



reply via email to

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