From: Peter Xu <peterx@redhat.com>
To: Steven Sistare <steven.sistare@oracle.com>
Cc: qemu-devel@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>,
"David Hildenbrand" <david@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Alex Williamson" <alex.williamson@redhat.com>
Subject: Re: [PATCH V2] memory: flat section iterator
Date: Tue, 7 Feb 2023 16:47:24 -0500 [thread overview]
Message-ID: <Y+LG7Ge3iSKho/oF@x1n> (raw)
In-Reply-To: <d2cf4bae-1a45-d2ae-8f47-f4ce56cf21dd@oracle.com>
On Tue, Feb 07, 2023 at 04:28:49PM -0500, Steven Sistare wrote:
> On 2/7/2023 3:10 PM, Peter Xu wrote:
> > On Tue, Feb 07, 2023 at 11:03:29AM -0800, Steve Sistare wrote:
> >> Add an iterator over the sections of a flattened address space.
> >> This will be needed by cpr to issue vfio ioctl's on the same memory
> >> ranges that are already programmed.
> >
> > Should this better be proposed with the context of using it? Or I don't
> > know how to justify this new interface is needed.
> >
> > For example, any explanations on why memory region listeners cannot work?
>
> For context, the new interfaces is used in the patch
> "vfio-pci: recover from unmap-all-vaddr failure"
> in the original live update series:
> https://lore.kernel.org/qemu-devel/1658851843-236870-1-git-send-email-steven.sistare@oracle.com/
>
> More succinctly, the memory region listeners already ran, and the vfio
> callbacks created vfio memory regions. Now we want to perform live update,
> and are in steady state, so no listeners are being called. We need the
> flat section iterator to reproduce the same addresses and extents that were
> produced by the listeners, to make a state change on each distinct vfio
> memory region.
Okay it makes sense, thanks.
I think it'll be the same as one memory_listener_register() followed by an
unregister with region_add() hooked only, but maybe we should avoid
fiddling with the global list of listeners when possible.
If you plan to keep posting it separately, would you add some information
into the commit message? With that enhanced, please feel free to add:
Acked-by: Peter Xu <peterx@redhat.com>
--
Peter Xu
next prev parent reply other threads:[~2023-02-07 21:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-07 19:03 [PATCH V2] memory: flat section iterator Steve Sistare
2023-02-07 20:10 ` Peter Xu
2023-02-07 21:28 ` Steven Sistare
2023-02-07 21:47 ` Peter Xu [this message]
2023-02-08 17:54 ` Steven Sistare
2023-02-08 13:48 ` David Hildenbrand
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=Y+LG7Ge3iSKho/oF@x1n \
--to=peterx@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=david@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=steven.sistare@oracle.com \
/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).