qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 23/35] vmstate: port arm cpu
Date: Fri, 04 May 2012 17:28:27 +0200	[thread overview]
Message-ID: <87k40s9d9g.fsf@elfo.elfo> (raw)
In-Reply-To: <CAFEAcA9eX5mmZ80M1vN0zB0SBH_Tfymh6iG6VnbT+0gfSSyyrA@mail.gmail.com> (Peter Maydell's message of "Fri, 4 May 2012 14:04:43 +0100")

Peter Maydell <peter.maydell@linaro.org> wrote:
> On 4 May 2012 11:54, Juan Quintela <quintela@redhat.com> wrote:
>> Use one subsection for each feature.  This means that we don't need to
>> bump the version field each time that a new feature gets introduced.
>>
>> Introduce cpsr_vmstate field, as I am not sure if I can "use"
>> uncached_cpsr for saving state.
>>
>> Signed-off-by: Juan Quintela <quintela@redhat.com>
>> ---
>>  target-arm/cpu.h     |    5 +-
>>  target-arm/machine.c |  344 ++++++++++++++++++++++----------------------------
>>  2 files changed, 156 insertions(+), 193 deletions(-)
>>
>> diff --git a/target-arm/cpu.h b/target-arm/cpu.h
>> index 9434902..37744c6 100644
>> --- a/target-arm/cpu.h
>> +++ b/target-arm/cpu.h
>> @@ -236,6 +236,9 @@ typedef struct CPUARMState {
>>     } cp[15];
>>     void *nvic;
>>     const struct arm_boot_info *boot_info;
>> +
>> +    /* Fields needed as intermediate for vmstate */
>> +    uint32_t cpsr_vmstate;
>>  } CPUARMState;
>
> I still think this is the wrong approach. We need to support
> "this is how you read/write this field" functions. See also
> target-alpha handling of the fpcr.

It is easy to change to support that (see alpha example), but then, each
time that we change protocol format (and we have a pending change for
1.2), every user that is "like" uint64_t, but with accesor and setter,
needs to get a new change.  This other way (with pre_save/post_load)
instead makes trivial to change protocols.

So, we can have "cleaniness" or "flexibility", take one.
I still think that alpha should be changed to this other approach, for
the same reason.

Notice that we _know_ that what we sent is an uint32_t, it is how we get
that uint32_t what changes, that is why I preffer a new field and
pre_load/post_load functions.

The only other sane approach that I can think is changing:

#define VMSTATE_INT32_V(_f, _s, _v)                                   \

into something like:

VMSTATE_INT32_GENERAL(_f, _s, _v, _getter, _setter)

and then _getter/_setter functions for normal ints the obvious copy this
uint32_t?

Would that work for you?



Later, Juan.

  reply	other threads:[~2012-05-04 15:28 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-04 10:54 [Qemu-devel] [PATCH v5 00/35] VMState port of all cpus Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 01/35] vmstate: Simplify test for CPU_SAVE_VERSION Juan Quintela
2012-05-04 11:46   ` Andreas Färber
2012-05-04 11:59     ` Juan Quintela
2012-05-04 12:06       ` Andreas Färber
2012-05-04 10:54 ` [Qemu-devel] [PATCH 02/35] vmstate: make all architectures export a way to migrate cpu's Juan Quintela
2012-05-04 16:16   ` Andreas Färber
2012-05-07 17:14     ` Andreas Färber
2012-05-04 10:54 ` [Qemu-devel] [PATCH 03/35] vmstate: unicore32 don't support cpu migration Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 04/35] vmstate: use new cpu style for x86 Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 05/35] vmstate: use new style for lm32 cpus Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 06/35] vmstate: make microblaze cpus not migrateable Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 07/35] vmstate: port cris cpu to vmstate Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 08/35] vmstate: introduce float32 arrays Juan Quintela
2012-05-04 12:00   ` Andreas Färber
2012-05-04 10:54 ` [Qemu-devel] [PATCH 09/35] vmstate: introduce float64 arrays Juan Quintela
2012-05-04 13:03   ` Andreas Färber
2012-05-04 10:54 ` [Qemu-devel] [PATCH 10/35] vmstate: introduce CPU_DoubleU arrays Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 11/35] vmstate: Introduce VMSTATE_STRUCT_VARRAY_INT32_TEST Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 12/35] vmstate: port ppc cpu Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 13/35] vmstate: introduce VMSTATE_VARRAY_MULTIPLY Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 14/35] vmstate: define vmstate_info_uinttls Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 15/35] vmstate: port sparc cpu Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 16/35] vmstate: make incompatible change for sparc Juan Quintela
2012-05-04 11:35   ` Andreas Färber
2012-05-04 13:00     ` Peter Maydell
2012-05-04 13:19       ` Andreas Färber
2012-05-06  8:59   ` Blue Swirl
2012-05-04 10:54 ` [Qemu-devel] [PATCH 17/35] mips_fulong2e: cpu vmstate already registered in cpu_exec_init Juan Quintela
2012-05-13 18:12   ` Andreas Färber
2012-05-04 10:54 ` [Qemu-devel] [PATCH 18/35] mips: make mvp an embedded struct instead of a pointer Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 19/35] mips: make tlb " Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 20/35] mips: bump migration version to 4 Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 21/35] vmstate: port mips cpu Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 22/35] arm: save always 32 fpu registers Juan Quintela
2012-05-04 12:44   ` Peter Maydell
2012-05-04 10:54 ` [Qemu-devel] [PATCH 23/35] vmstate: port arm cpu Juan Quintela
2012-05-04 13:04   ` Peter Maydell
2012-05-04 15:28     ` Juan Quintela [this message]
2012-05-04 15:37       ` Peter Maydell
2012-05-04 10:54 ` [Qemu-devel] [PATCH 24/35] vmstate: all cpus converted Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 25/35] vmstate: fix vmstate formating for i386 Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 26/35] vmstate: remove unneeded includes from target-*/machine.c Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 27/35] vmstate: rename machine.c to vmstate-cpu.c Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 28/35] vmstate: Add copyright info for alpha processor Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 29/35] vmstate: Add copyright info for lm32 processor Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 30/35] vmstate: Add copyright info for cris processor Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 31/35] vmstate: Add copyright info for arm processor Juan Quintela
2012-05-04 10:54 ` [Qemu-devel] [PATCH 32/35] vmstate: Add copyright info for i386 processor Juan Quintela
2012-05-04 10:55 ` [Qemu-devel] [PATCH 33/35] vmstate: Add copyright info for mips processor Juan Quintela
2012-05-04 10:55 ` [Qemu-devel] [PATCH 34/35] vmstate: Add copyright info for ppc processor Juan Quintela
2012-05-04 10:55 ` [Qemu-devel] [PATCH 35/35] vmstate: Add copyright info for sparc processor Juan Quintela
2012-05-04 11:19 ` [Qemu-devel] [PATCH v5 00/35] VMState port of all cpus Andreas Färber
2012-05-04 11:34   ` Juan Quintela
2012-05-04 11:35     ` Juan Quintela
2012-05-04 12:56       ` Anthony Liguori

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=87k40s9d9g.fsf@elfo.elfo \
    --to=quintela@redhat.com \
    --cc=peter.maydell@linaro.org \
    --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).