backend_registered was used to lazify the process of registering an
mmio region, since the it is different for the I/O address space and
the memory address space.  However, it also makes registration dependent
on the region being visible in the address space.  This is not the case
for "fake" regions, like watchpoints or IO_MEM_UNASSIGNED.

Remove backend_registered and always initialize the region.  If it turns
out to be part of the I/O address space, we've wasted an I/O slot, but
that's not too bad.  In any case this will be optimized later on.
Signed-off-by: NAvi Kivity <avi@redhat.com>
Reviewed-by: NRichard Henderson <rth@twiddle.net>

Currently creating a memory region automatically registers it for
live migration.  This differs from other state (which is enumerated
in a VMStateDescription structure) and ties the live migration code
into the memory core.

Decouple the two by introducing a separate API, vmstate_register_ram(),
for registering a RAM block for migration.  Currently the same
implementation is reused, but later it can be moved into a separate list,
and registrations can be moved to VMStateDescription blocks.
Signed-off-by: NAvi Kivity <avi@redhat.com>

Trivial accessor for the name attribute.
Signed-off-by: NAvi Kivity <avi@redhat.com>

This is a layering violation, but needed while the code contains
naked calls to qemu_get_ram_ptr() and the like.
Signed-off-by: NAvi Kivity <avi@redhat.com>

Add an API that allows a client to observe changes in the global
memory map:
 - region added (possibly with logging enabled)
 - region removed (possibly with logging enabled)
 - logging started on a region
 - logging stopped on a region
 - global logging started
 - global logging removed

This API will eventually replace cpu_register_physical_memory_client().
Signed-off-by: NAvi Kivity <avi@redhat.com>

The function is still used as the implementation.
Signed-off-by: NAvi Kivity <avi@redhat.com>

Given an address space (represented by the top-level memory region),
returns the memory region that maps a given range.  Useful for implementing
DMA.

The implementation is a simplistic binary search.  Once we have a tree
representation this can be optimized.
Signed-off-by: NAvi Kivity <avi@redhat.com>

Signed-off-by: NAvi Kivity <avi@redhat.com>

Signed-off-by: NAvi Kivity <avi@redhat.com>

Signed-off-by: NAvi Kivity <avi@redhat.com>

Fix typos and minor documentation errors in both memory.h and
docs/memory.txt.

Also add missing documentation formatting tags to transaction
functions.
Reviewed-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NAdemar de Souza Reis Jr <areis@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>

Add an API to update an alias offset of an active alias.  This can be
used to simplify implementation of dynamic memory banks.
Signed-off-by: NAvi Kivity <avi@redhat.com>

Allow changing the address of a memory region while it is
in the memory hierarchy.
Signed-off-by: NAvi Kivity <avi@redhat.com>

This allows users to disable a memory region without removing
it from the hierarchy, simplifying the implementation of
memory routers.
Signed-off-by: NAvi Kivity <avi@redhat.com>

MemoryRegionOps::valid tries to declaratively specify which transactions
are accepted by the device/bus, however it is not completely generic.  Add
a callback for special cases.
Signed-off-by: NAvi Kivity <avi@redhat.com>

Since the memory API supports 64-bit buses, it needs a larger type to represent
intermediate results.
Signed-off-by: NAvi Kivity <avi@redhat.com>

Add a monitor command 'info mtree' to show the memory hierarchy
much like /proc/iomem in Linux.
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>

The property is inheritable, but only if set to true.  This is so
that memory routers can mark sections of RAM as read-only via aliases.
Signed-off-by: NAvi Kivity <avi@redhat.com>

The MemoryRegionOps callbacks expect it.
Signed-off-by: NAvi Kivity <avi@redhat.com>

ROM/device regions act as mapped RAM for reads, can I/O memory for
writes.  This allow emulation of flash devices.
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

For consistency with other _END_OF_LIST macros.
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Allow changes to the memory hierarchy to be accumulated and
made visible all at once.  This reduces computational effort,
especially when an accelerator (e.g. kvm) is involved.

Useful when a single register update causes multiple changes
to an address space.
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

As with the rest of the memory API, the caller associates an eventfd
with an address, and the memory API takes care of registering or
unregistering when the address is made visible or invisible to the
guest.
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This eases the transition to the new API.
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Allow registering I/O ports via the same mechanism as mmio ranges.
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

For non-RAM memory regions, we cannot tell whether this is an I/O region
or an MMIO region.  Since the qemu backing registration is different for
the two, we have to defer initialization until we know which address
space we are in.

These shenanigans will be removed once the backing registration is unified
with the memory API.
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

I/O regions will not have ram_addrs, so this is a better name.
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Currently dirty tracking is implemented by passing through
all calls to the underlying cpu_physical_memory_*() calls.
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The memory API separates the attributes of a memory region (its size, how
reads or writes are handled, dirty logging, and coalescing) from where it
is mapped and whether it is enabled.  This allows a device to configure
a memory region once, then hand it off to its parent bus to map it according
to the bus configuration.

Hierarchical registration also allows a device to compose a region out of
a number of sub-regions with different properties; for example some may be
RAM while others may be MMIO.
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>