All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: "Cédric Le Goater" <clg@kaod.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
	Juan Quintela <quintela@redhat.com>,
	"Dr . David Alan Gilbert" <dgilbert@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:47:28 +0100	[thread overview]
Message-ID: <CAFEAcA8wJCSwtpypvH+3HKvv39o9bPC1vXJ_Co4VwiZTOt78ZA@mail.gmail.com> (raw)
In-Reply-To: <20180412101858.21304-1-clg@kaod.org>

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

> 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

  reply	other threads:[~2018-04-12 11:47 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 [this message]
2018-04-12 11:53   ` Dr. David Alan Gilbert
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=CAFEAcA8wJCSwtpypvH+3HKvv39o9bPC1vXJ_Co4VwiZTOt78ZA@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=alex.williamson@redhat.com \
    --cc=clg@kaod.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=kevin.tian@intel.com \
    --cc=kwankhede@nvidia.com \
    --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 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.