From: Juan Quintela <quintela@redhat.com>
To: "Cédric Le Goater" <clg@kaod.org>
Cc: qemu-devel@nongnu.org,
"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>,
kevin.tian@intel.com, joonas.lahtinen@linux.intel.com,
zhenyuw@linux.intel.com, kwankhede@nvidia.com,
zhi.a.wang@intel.com, Peter Maydell <peter.maydell@linaro.org>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v4] migration: discard non-migratable RAMBlocks
Date: Mon, 04 Jun 2018 05:55:54 +0200 [thread overview]
Message-ID: <87muwb8at1.fsf@secure.laptop> (raw)
In-Reply-To: <20180514065700.22202-1-clg@kaod.org> ("Cédric Le Goater"'s message of "Mon, 14 May 2018 08:57:00 +0200")
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 RAMBlock flag
> RAM_MIGRATABLE which is updated in the vmstate_register_ram() and
> vmstate_unregister_ram() routines. This flag is then used by the
> migration to identify RAMBlocks to discard on the source. Some checks
> are also performed on the destination to make sure nothing invalid was
> sent.
>
> This change impacts the boston, malta and jazz mips boards for which
> migration compatibility is broken.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Juan Quintela <quintela@redhat.com>
queued
prev parent reply other threads:[~2018-06-04 3:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-14 6:57 [Qemu-devel] [PATCH v4] migration: discard non-migratable RAMBlocks Cédric Le Goater
2018-05-14 7:04 ` no-reply
2018-05-15 14:19 ` Dr. David Alan Gilbert
2018-06-04 3:55 ` Juan Quintela [this message]
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=87muwb8at1.fsf@secure.laptop \
--to=quintela@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=clg@kaod.org \
--cc=david@gibson.dropbear.id.au \
--cc=dgilbert@redhat.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=kevin.tian@intel.com \
--cc=kwankhede@nvidia.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--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.