From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, imammedo@redhat.com,
maxime.coquelin@redhat.com, groug@kaod.org, mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH v3 1/8] memory: address_space_iterate
Date: Tue, 12 Dec 2017 11:03:58 +0000 [thread overview]
Message-ID: <20171212110357.GD2409@work-vm> (raw)
In-Reply-To: <7677f3f3-72b9-0f0c-13ca-ace1196ed45b@redhat.com>
* Paolo Bonzini (pbonzini@redhat.com) wrote:
> On 12/12/2017 11:31, Dr. David Alan Gilbert wrote:
> > * Paolo Bonzini (pbonzini@redhat.com) wrote:
> >> On 11/12/2017 20:46, Dr. David Alan Gilbert (git) wrote:
> >>> From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> >>>
> >>> Iterate through an address space calling a function for each
> >>> section. The iteration is done in order.
> >>>
> >>> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> >>
> >> It seems to me that you can achieve the same effect by implementing the
> >> region_add and region_nop callbacks, and leaving out region_del. Am I
> >> missing something?
> >
> > What's the semantics of region_nop (and for that matter region_add/del)?
>
> nop means that attributes (readonly, romd_mode, mr+offset_in_region)
> haven't changed; nop is optionally followed by log_start or log_stop.
> If any of them changes, you get del+add (del is always before add).
>
> > Th nice thing we have here is we get a full walk of the physical memory
> > in order; keeping it in order makes our data structure easy for merging.
>
> That's the same that you get with region_del/add.
Hmm it would be good if that was documented somewhere.
I thought you'd only get an _add/_del and then a commit.
However, what do I do in vhost_dev_start? At the moment I'm forcfully
regenerating it using the same code.
Dave
> Thanks,
>
> Paolo
>
> > Dave
> >
> >
> >> Thanks,
> >>
> >> Paolo
> >>
> >>> ---
> >>> include/exec/memory.h | 23 +++++++++++++++++++++++
> >>> memory.c | 22 ++++++++++++++++++++++
> >>> 2 files changed, 45 insertions(+)
> >>>
> >>> diff --git a/include/exec/memory.h b/include/exec/memory.h
> >>> index 5ed4042f87..f5a9df642e 100644
> >>> --- a/include/exec/memory.h
> >>> +++ b/include/exec/memory.h
> >>> @@ -1987,6 +1987,29 @@ address_space_write_cached(MemoryRegionCache *cache, hwaddr addr,
> >>> address_space_write(cache->as, cache->xlat + addr, MEMTXATTRS_UNSPECIFIED, buf, len);
> >>> }
> >>>
> >>> +/**
> >>> + * ASIterateCallback: Function type called by address_space_iterate
> >>> + *
> >>> + * Return 0 on success or a negative error code.
> >>> + *
> >>> + * @mrs: Memory region section for this range
> >>> + * @opaque: The opaque value passed in to the iterator.
> >>> + */
> >>> +typedef int (*ASIterateCallback)(MemoryRegionSection *mrs, void *opaque);
> >>> +
> >>> +/**
> >>> + * address_space_iterate: Call the function for each address range in the
> >>> + * AddressSpace, in sorted order.
> >>> + *
> >>> + * Return 0 on success or a negative error code.
> >>> + *
> >>> + * @as: Address space to iterate over
> >>> + * @cb: Function to call. If the function returns none-0 the iteration will
> >>> + * stop.
> >>> + * @opaque: Value to pass to the function
> >>> + */
> >>> +int
> >>> +address_space_iterate(AddressSpace *as, ASIterateCallback cb, void *opaque);
> >>> #endif
> >>>
> >>> #endif
> >>> diff --git a/memory.c b/memory.c
> >>> index e26e5a3b1d..f45137f25e 100644
> >>> --- a/memory.c
> >>> +++ b/memory.c
> >>> @@ -2810,6 +2810,28 @@ void address_space_destroy(AddressSpace *as)
> >>> call_rcu(as, do_address_space_destroy, rcu);
> >>> }
> >>>
> >>> +int address_space_iterate(AddressSpace *as, ASIterateCallback cb,
> >>> + void *opaque)
> >>> +{
> >>> + int res = 0;
> >>> + FlatView *fv = address_space_to_flatview(as);
> >>> + FlatRange *range;
> >>> +
> >>> + flatview_ref(fv);
> >>> +
> >>> + FOR_EACH_FLAT_RANGE(range, fv) {
> >>> + MemoryRegionSection mrs = section_from_flat_range(range, fv);
> >>> + res = cb(&mrs, opaque);
> >>> + if (res) {
> >>> + break;
> >>> + }
> >>> + }
> >>> +
> >>> + flatview_unref(fv);
> >>> +
> >>> + return res;
> >>> +}
> >>> +
> >>> static const char *memory_region_type(MemoryRegion *mr)
> >>> {
> >>> if (memory_region_is_ram_device(mr)) {
> >>>
> >>
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> >
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2017-12-12 11:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-11 19:46 [Qemu-devel] [PATCH v3 0/8] Rework vhost memory region updates Dr. David Alan Gilbert (git)
2017-12-11 19:46 ` [Qemu-devel] [PATCH v3 1/8] memory: address_space_iterate Dr. David Alan Gilbert (git)
2017-12-11 23:50 ` Paolo Bonzini
2017-12-12 10:23 ` Igor Mammedov
2017-12-12 10:31 ` Dr. David Alan Gilbert
2017-12-12 10:50 ` Paolo Bonzini
2017-12-12 11:03 ` Dr. David Alan Gilbert [this message]
2017-12-12 11:28 ` Paolo Bonzini
2017-12-11 19:46 ` [Qemu-devel] [PATCH v3 2/8] vhost: Move log_dirty check Dr. David Alan Gilbert (git)
2017-12-11 19:46 ` [Qemu-devel] [PATCH v3 3/8] vhost: Simplify ring verification checks Dr. David Alan Gilbert (git)
2017-12-11 19:46 ` [Qemu-devel] [PATCH v3 4/8] vhost: New memory update functions Dr. David Alan Gilbert (git)
2017-12-11 19:46 ` [Qemu-devel] [PATCH v3 5/8] vhost: update_mem_cb implementation Dr. David Alan Gilbert (git)
2017-12-11 19:46 ` [Qemu-devel] [PATCH v3 6/8] vhost: Compare and copy updated region data into device state Dr. David Alan Gilbert (git)
2017-12-11 19:46 ` [Qemu-devel] [PATCH v3 7/8] vhost: Remove old vhost_set_memory etc Dr. David Alan Gilbert (git)
2017-12-11 19:46 ` [Qemu-devel] [PATCH v3 8/8] vhost: Move mem_sections maintenance into commit/update routines Dr. David Alan Gilbert (git)
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=20171212110357.GD2409@work-vm \
--to=dgilbert@redhat.com \
--cc=groug@kaod.org \
--cc=imammedo@redhat.com \
--cc=maxime.coquelin@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).