From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: quintela@redhat.com
Cc: Alexander Graf <agraf@suse.de>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] vm state save/restore question
Date: Wed, 20 Jun 2012 09:28:32 +1000 [thread overview]
Message-ID: <1340148512.28143.52.camel@pasglop> (raw)
In-Reply-To: <87y5nij3r6.fsf@elfo.mitica>
On Wed, 2012-06-20 at 01:11 +0200, Juan Quintela wrote:
>
> > I am confident I can come up with something as far as the kernel and
> > qemu <-> kernel interface goes. I need to get my head around the details
> > on how to implement that two stage save process in qemu though and the
> > corresponding restore which will need to read both snapshots and apply
> > the diff before shooting it back to the kernel.
> >
> > BTW. Does migration in pure qemu (full system emu) works similarily, ie,
> > two stage ? If it does I can easily prototype everything there.
>
> It does, but I have no clue how the hashed page tables are implemented
> on ppc, i.e. if there is anything specific for bare metal. Alex?
We support the paravirtualized -M pseries in full emu as well, in which
case the hashed page table is handled by qemu itself who implements the
H_ENTER & co hypercalls. So it's very similar, except that qemu doesn't
have to ask the kernel to get a snapshot :-)
So I can flush out the storage format and two stage process inside qemu,
and then bother with the kvm/kernel interface.
Normal "bare metal" operation in qemu (or even KVM "PR") doesn't require
this as in that case the hash table is just a normal part of the guest
memory, it's only an issue when doing paravirtualized guest such as
pseries (aka PAPR).
Cheers,
Ben.
next prev parent reply other threads:[~2012-06-19 23:28 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-09 10:53 [Qemu-devel] vm state save/restore question Benjamin Herrenschmidt
2012-06-09 11:34 ` Benjamin Herrenschmidt
2012-06-09 11:37 ` Andreas Färber
2012-06-19 14:07 ` Alexander Graf
2012-06-19 14:59 ` Juan Quintela
2012-06-19 17:16 ` Andreas Färber
2012-06-19 20:30 ` Benjamin Herrenschmidt
2012-06-19 21:00 ` Alexander Graf
2012-06-19 21:13 ` Benjamin Herrenschmidt
2012-06-19 21:48 ` Alexander Graf
2012-06-19 21:51 ` Benjamin Herrenschmidt
2012-06-19 22:27 ` Alexander Graf
2012-06-19 22:32 ` Benjamin Herrenschmidt
2012-06-19 22:55 ` Juan Quintela
2012-06-19 23:00 ` Benjamin Herrenschmidt
2012-06-19 23:11 ` Juan Quintela
2012-06-19 23:28 ` Benjamin Herrenschmidt [this message]
2012-06-19 23:30 ` Alexander Graf
2012-06-19 23:52 ` Benjamin Herrenschmidt
2012-06-20 0:05 ` Alexander Graf
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=1340148512.28143.52.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=agraf@suse.de \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.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.