From: Avi Kivity <avi@redhat.com>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [RFC v1] Add declarations for hierarchical memory region API
Date: Fri, 20 May 2011 12:20:35 +0300 [thread overview]
Message-ID: <4DD63263.7090106@redhat.com> (raw)
In-Reply-To: <4DD56F3B.70205@web.de>
On 05/19/2011 10:27 PM, Jan Kiszka wrote:
> 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.
Okay.
> > +/* 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?
Look at e1000, coalescing ranges have byte granularity.
> > +/* Disable MMIO coalescing for the region. */
> > +void memory_region_clear_coalescing(MemoryRegion *mr);
>
> And what about clearing coalescing for sub-ranges?
Clear them all and rebuild.
> Maybe skip
> add_coalescing for the first run and see how far we get.
We get as far as e.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi@redhat.com>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [RFC v1] Add declarations for hierarchical memory region API
Date: Fri, 20 May 2011 12:20:35 +0300 [thread overview]
Message-ID: <4DD63263.7090106@redhat.com> (raw)
In-Reply-To: <4DD56F3B.70205@web.de>
On 05/19/2011 10:27 PM, Jan Kiszka wrote:
> 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.
Okay.
> > +/* 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?
Look at e1000, coalescing ranges have byte granularity.
> > +/* Disable MMIO coalescing for the region. */
> > +void memory_region_clear_coalescing(MemoryRegion *mr);
>
> And what about clearing coalescing for sub-ranges?
Clear them all and rebuild.
> Maybe skip
> add_coalescing for the first run and see how far we get.
We get as far as e.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
next prev parent reply other threads:[~2011-05-20 9:20 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 [this message]
2011-05-20 9:20 ` 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=4DD63263.7090106@redhat.com \
--to=avi@redhat.com \
--cc=jan.kiszka@web.de \
--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.