qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: qemu-devel@nongnu.org
Cc: Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] vm state save/restore question
Date: Sat, 09 Jun 2012 21:34:02 +1000	[thread overview]
Message-ID: <1339241642.24838.92.camel@pasglop> (raw)
In-Reply-To: <1339239192.24838.84.camel@pasglop>

On Sat, 2012-06-09 at 20:53 +1000, Benjamin Herrenschmidt wrote:
> Hi folks !

(After some discussion with Andreas ...)

> I'm looking at sorting out the state save/restore of target-ppc (which
> means understanding in general how it works in qemu :-)
> 
> So far I've somewhat figured out that there's the "old way" where we
> just provide a "bulk" save/restore function pair, and the "new way"
> where we have nicely tagged field lists etc...
> 
> x86 seems to use the later for the CPU state, ppc is a mess and uses the
> former with interesting incompatible format change depending on how qemu
> is build :-) So I think that's one area I need to fix.

Ok, so I'm told there are patches to convert ppc, I haven't seen them in
my list archives, so if somebody has a pointer, please shoot, that will
save me some work :-)

  .../...

> What I'd need is something in spapr that can be used to "resync" bits of
> the cpu state with the external htab that gets run after everything is
> loaded and before emulation restarts.
> 
> Any idea how to do that properly ? I suppose I could also try to iterate
> all the vcpu's after loading the hash table & update the fields but not
> only that's gross ... I also don't know how to do it :-)

So I did an experiment using the "old style" save/restore (bad boy !)
and got that part to work by just iterating the vcpu's.

It's a bit nasty but it's the right way I think, ie, what we have here
(the external hash table) is a global object under control/ownership of
the platform code for which a pointer is cached in the CPU state (so the
mmu emulation gets to it easily), so those cached pointers need to be
updated in all CPUs when a new hash table is loaded/allocated.

That leads to another question however... I need to add save/restore to
a bunch more stuff such as the xics (interrupt controller), the various
spapr devices, etc...

So far the VMState stuff is all nice if you have fixed sized arrays.
However I haven't quite found out the right way to use it for things
like:

 - The hash table (mentioned above). This is just a big chunk of memory
(it will routinely be 16M), so I really don't want to start iterating
all elements, just a bulk load will do, and the size might actually be
variable.

 - The XICS (interrupt controller). The actual size of the interrupt
state array can vary (the number of interrupt sources can vary, it's
fixed today by the machine code but I wouldn't rely too much on that and
in any case, from the XICS driver perspective, it's not a constant, it's
a variable it gets passed when initializing).

So in both these cases, I need either code to control the save/load
process (old style ? hard to hook into vmstate as far as I can tell) or
maybe a way to describe the array so that the array size itself is a
pointer to a variable (Andreas mentioned something along those lines).
Is there any doco for that stuff btw ? I haven't seen anything
detailed...

Suggestions ?

Cheers,
Ben.

  reply	other threads:[~2012-06-09 11:34 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 [this message]
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
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=1339241642.24838.92.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=agraf@suse.de \
    --cc=qemu-devel@nongnu.org \
    /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).