From: Stefan Weil <weil@mail.berlios.de>
To: Avi Kivity <avi@redhat.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [RFC v1] Add declarations for hierarchical memory region API
Date: Thu, 19 May 2011 23:04:10 +0200 [thread overview]
Message-ID: <4DD585CA.4070102@mail.berlios.de> (raw)
In-Reply-To: <1305814352-15044-2-git-send-email-avi@redhat.com>
Am 19.05.2011 16:12, schrieb Avi Kivity:
> 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.
>
> Signed-off-by: Avi Kivity <avi@redhat.com>
> ---
> memory.h | 142
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 142 insertions(+), 0 deletions(-)
> create mode 100644 memory.h
>
> diff --git a/memory.h b/memory.h
> new file mode 100644
> index 0000000..77c5951
> --- /dev/null
> +++ b/memory.h
> @@ -0,0 +1,142 @@
> +#ifndef MEMORY_H
> +#define MEMORY_H
> +
> +#include <stdint.h>
> +#include <stdbool.h>
stdbool.h is already included in qemu-common.h,
stdint.h (indirectly) too.
Therefore both include statements can be removed.
> +#include "qemu-common.h"
> +#include "cpu-common.h"
> +#include "targphys.h"
> +#include "qemu-queue.h"
> +
> +typedef struct MemoryRegionOps MemoryRegionOps;
> +typedef struct MemoryRegion MemoryRegion;
> +
> +/*
> + * Memory region callbacks
> + */
> +struct MemoryRegionOps {
> + /* Read from the memory region. @addr is relative to @mr; @size is
> + * in bytes. */
> + uint64_t (*read)(MemoryRegion *mr,
> + target_phys_addr_t addr,
> + unsigned size);
> + /* Write to the memory region. @addr is relative to @mr; @size is
> + * in bytes. */
> + void (*write)(MemoryRegion *mr,
> + target_phys_addr_t addr,
> + uint64_t data,
> + unsigned size);
> + /* Guest-visible constraints: */
> + struct {
> + /* If nonzero, specify bounds on access sizes beyond which a machine
> + * check is thrown.
> + */
> + unsigned min_access_size;
> + unsigned max_access_size;
> + /* If true, unaligned accesses are supported. Otherwise unaligned
> + * accesses throw machine checks.
> + */
> + bool unaligned;
> + } valid;
> + /* Internal implementation constraints: */
> + struct {
> + /* If nonzero, specifies the minimum size implemented. Smaller sizes
> + * will be rounded upwards and a partial result will be returned.
> + */
> + unsigned min_access_size;
> + /* If nonzero, specifies the maximum size implemented. Larger sizes
> + * will be done as a series of accesses with smaller sizes.
> + */
> + unsigned max_access_size;
> + /* If true, unaligned accesses are supported. Otherwise all accesses
> + * are converted to (possibly multiple) naturally aligned accesses.
> + */
> + bool unaligned;
> + } impl;
> +};
> +
> +typedef struct CoalescedMemoryRange CoalescedMemoryRange;
> +
> +struct CoalescedMemoryRange {
> + target_phys_addr_t start;
> + target_phys_addr_t size;
> + QTAILQ_ENTRY(coalesced_ranges) link;
> +};
> +
> +struct MemoryRegion {
> + /* All fields are private - violators will be prosecuted */
Is it possible to move this private declaration into the implementation
file (or a private header file if the declaration is needed by more than
one file)?
> + const MemoryRegionOps *ops;
> + MemoryRegion *parent;
> + target_phys_addr_t size;
> + target_phys_addr_t addr;
> + ram_addr_t ram_addr;
> + unsigned priority;
> + bool may_overlap;
> + QTAILQ_HEAD(subregions, MemoryRegion) subregions;
> + QTAILQ_ENTRY(subregions) subregions_link;
> + QTAILQ_HEAD(coalesced_ranges, CoalescedMemoryRange) coalesced;
> +};
> +
> +/* Initialize a memory region
> + *
> + * The region typically acts as a container for other memory regions.
> + */
> +void memory_region_init(MemoryRegion *mr,
> + target_phys_addr_t size);
> +/* Initialize an I/O memory region. Accesses into the region will be
> + * cause the callbacks in @ops to be called.
> + *
> + * if @size is nonzero, subregions will be clipped to @size.
> + */
> +void memory_region_init_io(MemoryRegion *mr,
> + const MemoryRegionOps *ops,
> + target_phys_addr_t size);
> +/* Initialize an I/O memory region. Accesses into the region will be
> + * modify memory directly.
> + */
> +void memory_region_init_ram(MemoryRegion *mr,
> + target_phys_addr_t size);
> +/* Initialize a RAM memory region. Accesses into the region will be
> + * modify memory in @ptr directly.
> + */
> +void memory_region_init_ram_ptr(MemoryRegion *mr,
> + target_phys_addr_t size,
> + void *ptr);
> +/* Destroy a memory region. The memory becomes inaccessible. */
> +void memory_region_destroy(MemoryRegion *mr);
> +/* Sets an offset to be added to MemoryRegionOps callbacks. */
> +void memory_region_set_offset(MemoryRegion *mr, target_phys_addr_t
> offset);
> +/* Turn loggging on or off for specified client (display, migration) */
> +void memory_region_set_log(MemoryRegion *mr, bool log, unsigned client);
> +/* Enable memory coalescing for the region. MMIO ->write callbacks may be
> + * delayed until a non-coalesced MMIO is issued.
> + */
> +void memory_region_set_coalescing(MemoryRegion *mr);
> +/* Enable memory coalescing for a sub-range of the region. MMIO ->write
> + * callbacks may be delayed until a non-coalesced MMIO is issued.
> + */
> +void memory_region_add_coalescing(MemoryRegion *mr,
> + target_phys_addr_t offset,
> + target_phys_addr_t size);
> +/* Disable MMIO coalescing for the region. */
> +void memory_region_clear_coalescing(MemoryRegion *mr);
> +
> +/* Add a sub-region at @offset. The sub-region may not overlap with other
> + * subregions (except for those explicitly marked as overlapping)
> + */
> +void memory_region_add_subregion(MemoryRegion *mr,
> + target_phys_addr_t offset,
> + MemoryRegion *subregion);
> +/* Add a sub-region at @offset. The sun-region may overlap other
> subregions;
> + * conflicts are resolved by having a higher @priority hide a lower
> @priority.
> + * Subregions without priority are taken as @priority 0.
> + */
> +void memory_region_add_subregion_overlap(MemoryRegion *mr,
> + target_phys_addr_t offset,
> + MemoryRegion *subregion,
> + unsigned priority);
> +/* Remove a subregion. */
> +void memory_region_del_subregion(MemoryRegion *mr,
> + MemoryRegion *subregion);
> +
> +#endif
Kind regards,
Stefan W.
next prev parent reply other threads:[~2011-05-19 21:04 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-19 14:12 [RFC v1] Memory API Avi Kivity
2011-05-19 14:12 ` [Qemu-devel] " Avi Kivity
2011-05-19 14:12 ` [RFC v1] Add declarations for hierarchical memory region API Avi Kivity
2011-05-19 14:12 ` [Qemu-devel] " Avi Kivity
2011-05-19 19:07 ` Alex Williamson
2011-05-20 9:18 ` Avi Kivity
2011-05-20 9:18 ` [Qemu-devel] " Avi Kivity
2011-05-19 19:27 ` Jan Kiszka
2011-05-19 19:27 ` [Qemu-devel] " Jan Kiszka
2011-05-20 9:20 ` Avi Kivity
2011-05-20 9:20 ` [Qemu-devel] " Avi Kivity
2011-05-19 20:43 ` Anthony Liguori
2011-05-20 9:23 ` Avi Kivity
2011-05-20 14:06 ` Richard Henderson
2011-05-20 14:06 ` Richard Henderson
2011-05-20 14:31 ` Anthony Liguori
2011-05-20 14:31 ` Anthony Liguori
2011-05-20 14:40 ` Richard Henderson
2011-05-20 14:40 ` Richard Henderson
2011-05-20 14:46 ` Anthony Liguori
2011-05-20 18:16 ` Blue Swirl
2011-05-20 18:16 ` Blue Swirl
2011-05-22 6:40 ` Avi Kivity
2011-05-22 6:40 ` Avi Kivity
2011-05-22 6:39 ` Avi Kivity
2011-05-22 6:39 ` [Qemu-devel] " Avi Kivity
2011-05-22 15:46 ` Anthony Liguori
2011-05-22 15:52 ` Avi Kivity
2011-05-22 6:38 ` Avi Kivity
2011-05-22 6:38 ` Avi Kivity
2011-05-22 15:44 ` Anthony Liguori
2011-05-22 15:44 ` [Qemu-devel] " Anthony Liguori
2011-05-22 15:56 ` Avi Kivity
2011-05-22 15:56 ` [Qemu-devel] " Avi Kivity
2011-05-22 7:01 ` Avi Kivity
2011-05-22 7:01 ` [Qemu-devel] " Avi Kivity
2011-05-19 21:04 ` Stefan Weil [this message]
2011-05-20 9:26 ` Avi Kivity
2011-05-19 21:11 ` Stefan Hajnoczi
2011-05-19 21:11 ` [Qemu-devel] " Stefan Hajnoczi
2011-05-20 9:28 ` Avi Kivity
2011-05-20 9:28 ` [Qemu-devel] " Avi Kivity
2011-05-20 17:59 ` Blue Swirl
2011-05-22 6:45 ` Avi Kivity
2011-05-22 9:32 ` Blue Swirl
2011-05-22 9:32 ` [Qemu-devel] " Blue Swirl
2011-05-22 11:36 ` Avi Kivity
2011-05-22 12:06 ` Blue Swirl
2011-05-22 12:18 ` Avi Kivity
2011-05-22 15:32 ` Blue Swirl
2011-05-22 15:36 ` Avi Kivity
2011-05-22 7:04 ` Avi Kivity
2011-05-22 7:04 ` [Qemu-devel] " Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DD585CA.4070102@mail.berlios.de \
--to=weil@mail.berlios.de \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.