From: Jan Kiszka <jan.kiszka@web.de>
To: Avi Kivity <avi@redhat.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [RFC v1] Add declarations for hierarchical memory region API
Date: Thu, 19 May 2011 21:27:55 +0200 [thread overview]
Message-ID: <4DD56F3B.70205@web.de> (raw)
In-Reply-To: <1305814352-15044-2-git-send-email-avi@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]
On 2011-05-19 16:12, Avi Kivity wrote:
> +/* Sets an offset to be added to MemoryRegionOps callbacks. */
> +void memory_region_set_offset(MemoryRegion *mr, target_phys_addr_t offset);
Please mark this as a legacy helper, ideally to be removed after the
complete conversion to this API. During that phase we should try to
identify those devices which still depend on offset=0 and maybe directly
fix them.
> +/* 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);
Will this be such a common use case that requesting the user to split up
the region and then use set_coalescing will generate too much boiler
plate code?
> +/* Disable MMIO coalescing for the region. */
> +void memory_region_clear_coalescing(MemoryRegion *mr);
And what about clearing coalescing for sub-ranges? Maybe skip
add_coalescing for the first run and see how far we get.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Jan Kiszka <jan.kiszka@web.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 21:27:55 +0200 [thread overview]
Message-ID: <4DD56F3B.70205@web.de> (raw)
In-Reply-To: <1305814352-15044-2-git-send-email-avi@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]
On 2011-05-19 16:12, Avi Kivity wrote:
> +/* Sets an offset to be added to MemoryRegionOps callbacks. */
> +void memory_region_set_offset(MemoryRegion *mr, target_phys_addr_t offset);
Please mark this as a legacy helper, ideally to be removed after the
complete conversion to this API. During that phase we should try to
identify those devices which still depend on offset=0 and maybe directly
fix them.
> +/* 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);
Will this be such a common use case that requesting the user to split up
the region and then use set_coalescing will generate too much boiler
plate code?
> +/* Disable MMIO coalescing for the region. */
> +void memory_region_clear_coalescing(MemoryRegion *mr);
And what about clearing coalescing for sub-ranges? Maybe skip
add_coalescing for the first run and see how far we get.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
next prev parent reply other threads:[~2011-05-19 19:27 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 [this message]
2011-05-19 19:27 ` 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
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=4DD56F3B.70205@web.de \
--to=jan.kiszka@web.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.