From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Cédric Le Goater" <clg@kaod.org>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Juan Quintela" <quintela@redhat.com>,
"David Gibson" <david@gibson.dropbear.id.au>,
"Alex Williamson" <alex.williamson@redhat.com>,
"Yulei Zhang" <yulei.zhang@intel.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
joonas.lahtinen@linux.intel.com, zhenyuw@linux.intel.com,
"Kirti Wankhede" <kwankhede@nvidia.com>,
zhi.a.wang@intel.com, "Eric Blake" <eblake@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] migration: discard RAMBlocks of type ram_device
Date: Thu, 12 Apr 2018 12:53:26 +0100 [thread overview]
Message-ID: <20180412115326.GF2704@work-vm> (raw)
In-Reply-To: <CAFEAcA8wJCSwtpypvH+3HKvv39o9bPC1vXJ_Co4VwiZTOt78ZA@mail.gmail.com>
* Peter Maydell (peter.maydell@linaro.org) wrote:
> On 12 April 2018 at 11:18, Cédric Le Goater <clg@kaod.org> wrote:
> > On the POWER9 processor, the XIVE interrupt controller can control
> > interrupt sources using MMIO to trigger events, to EOI or to turn off
> > the sources. Priority management and interrupt acknowledgment is also
> > controlled by MMIO in the presenter sub-engine.
> >
> > These MMIO regions are exposed to guests in QEMU with a set of 'ram
> > device' memory mappings, similarly to VFIO, and the VMAs are populated
> > dynamically with the appropriate pages using a fault handler.
> >
> > But, these regions are an issue for migration. We need to discard the
> > associated RAMBlocks from the RAM state on the source VM and let the
> > destination VM rebuild the memory mappings on the new host in the
> > post_load() operation just before resuming the system.
> >
> > To achieve this goal, the following introduces a new helper,
> > ram_block_is_migratable(), which identifies RAMBlocks to discard on
> > the source. Some checks are also performed on the destination to make
> > sure nothing invalid was sent.
>
> David suggested on IRC that we would want a flag on the ramblock
> for "not migratable", because there are other uses for "don't
> migrate this" than just "is this a ram device".
My original suggestion to your series was with a flag, but I'd forgotten
about that by the time I'd made the suggestion to Cédric.
In your case would just adding an extra term to the
ram_block_is_migratable function work, or do you really need a flag?
Dave
> > Signed-off-by: Cédric Le Goater <clg@kaod.org>
> > ---
> >
> > I am not sure we want to taker into account patchew complaint :
> >
> > ERROR: braces {} are necessary for all arms of this statement
> > #52: FILE: migration/ram.c:203:
> > + if (ram_block_is_migratable(block))
> > [...]
> >
> > total: 1 errors, 0 warnings, 136 lines checked
> >
> > migration/ram.c | 52 ++++++++++++++++++++++++++++++++++++++++++----------
> > 1 file changed, 42 insertions(+), 10 deletions(-)
> >
> > diff --git a/migration/ram.c b/migration/ram.c
> > index 0e90efa09236..32371950865b 100644
> > --- a/migration/ram.c
> > +++ b/migration/ram.c
> > @@ -188,6 +188,21 @@ void ramblock_recv_bitmap_set_range(RAMBlock *rb, void *host_addr,
> > }
> >
> > /*
> > + * Identifies RAM blocks which should be discarded from migration. For
> > + * the moment, it only applies to blocks backed by a 'ram_device'
> > + * memory region.
> > + */
> > +static inline bool ram_block_is_migratable(RAMBlock *block)
> > +{
> > + return !memory_region_is_ram_device(block->mr);
> > +}
> > +
> > +/* Should be holding either ram_list.mutex, or the RCU lock. */
> > +#define RAMBLOCK_FOREACH_MIGRATABLE(block) \
> > + RAMBLOCK_FOREACH(block) \
> > + if (ram_block_is_migratable(block))
>
> This will mishandle some uses, like:
>
> if (foo)
> RAMBLOCK_FOREACH_MIGRATABLE(block)
> stuff;
> else
> morestuff;
>
> as the if() inside the macro will capture the else clause.
> (The lack of braces in the calling code would be against our
> coding style, of course, so not very likely.)
>
> Eric, is there a 'standard' trick for this? I thought of
> maybe
>
> #define RAMBLOCK_FOREACH_MIGRATABLE(block) \
> RAMBLOCK_FOREACH(block) \
> if (!ram_block_is_migratable(block)) {} else
>
> ?
>
> thanks
> -- PMM
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2018-04-12 11:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-12 10:18 [Qemu-devel] [PATCH] migration: discard RAMBlocks of type ram_device Cédric Le Goater
2018-04-12 11:47 ` Peter Maydell
2018-04-12 11:53 ` Dr. David Alan Gilbert [this message]
2018-04-12 12:08 ` Peter Maydell
2018-04-12 13:41 ` Cédric Le Goater
2018-04-12 13:51 ` Peter Maydell
2018-04-12 14:11 ` Paolo Bonzini
2018-04-12 15:16 ` Cédric Le Goater
2018-04-12 15:14 ` Eric Blake
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=20180412115326.GF2704@work-vm \
--to=dgilbert@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=clg@kaod.org \
--cc=david@gibson.dropbear.id.au \
--cc=eblake@redhat.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=kevin.tian@intel.com \
--cc=kwankhede@nvidia.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=yulei.zhang@intel.com \
--cc=zhenyuw@linux.intel.com \
--cc=zhi.a.wang@intel.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).