From: Peter Lieven <pl@kamp.de>
To: Peter Lieven <pl@kamp.de>
Cc: quintela@redhat.com, aik@ozlabs.ru, qemu-devel@nongnu.org,
owasserm@redhat.com, pbonzini@redhat.com,
xiawenc@linux.vnet.ibm.com, david@gibson.dropbear.id.au
Subject: Re: [Qemu-devel] [PATCH] migration: ensure memory is zeroized at the destination
Date: Mon, 10 Jun 2013 11:58:41 +0200 [thread overview]
Message-ID: <51B5A351.4010401@kamp.de> (raw)
In-Reply-To: <1370847839-5594-1-git-send-email-pl@kamp.de>
please ignore this one.
Peter
On 10.06.2013 09:03, Peter Lieven wrote:
> migration relies on the target memory to be zeroed out since commit
> f1c72795 (migration: do not sent zero pages in bulk stage). however,
> there is a subtle case where this breaks migration. if for some reason
> a page is zero at the source but not at the destination the destination
> memory is corrupted.
>
> this was reported to break migration on pseries and also other platforms
> might be affected. to ultimatively make sure the destination memory is zero
> at the destination check for it on negotiation of ram blocks.
>
> note: the better fix for this would be to pass a flag to the machine
> init functions of all architectures to indicate that the machine is a
> migration target and then avoid copying ram images etc. to physical
> ram in this case. but this would require a lot of code to be changed
> and reviewed.
>
> Signed-off-by: Peter Lieven <pl@kamp.de>
> ---
> arch_init.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch_init.c b/arch_init.c
> index 5d32ecf..458bf8c 100644
> --- a/arch_init.c
> +++ b/arch_init.c
> @@ -799,6 +799,8 @@ static int ram_load(QEMUFile *f, void *opaque, int version_id)
> while (total_ram_bytes) {
> RAMBlock *block;
> uint8_t len;
> + void *base;
> + ram_addr_t offset;
>
> len = qemu_get_byte(f);
> qemu_get_buffer(f, (uint8_t *)id, len);
> @@ -822,6 +824,14 @@ static int ram_load(QEMUFile *f, void *opaque, int version_id)
> goto done;
> }
>
> + base = memory_region_get_ram_ptr(block->mr);
> + for (offset = 0; offset < block->length;
> + offset += TARGET_PAGE_SIZE) {
> + if (!is_zero_page(base + offset)) {
> + memset(base + offset, 0x00, TARGET_PAGE_SIZE);
> + }
> + }
> +
> total_ram_bytes -= length;
> }
> }
--
Mit freundlichen Grüßen
Peter Lieven
...........................................................
KAMP Netzwerkdienste GmbH
Vestische Str. 89-91 | 46117 Oberhausen
Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40
pl@kamp.de | http://www.kamp.de
Geschäftsführer: Heiner Lante | Michael Lante
Amtsgericht Duisburg | HRB Nr. 12154
USt-Id-Nr.: DE 120607556
...........................................................
prev parent reply other threads:[~2013-06-10 9:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-10 7:03 [Qemu-devel] [PATCH] migration: ensure memory is zeroized at the destination Peter Lieven
2013-06-10 9:58 ` Peter Lieven [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=51B5A351.4010401@kamp.de \
--to=pl@kamp.de \
--cc=aik@ozlabs.ru \
--cc=david@gibson.dropbear.id.au \
--cc=owasserm@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=xiawenc@linux.vnet.ibm.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).