qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).