[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/5] VMState cleanups
From: |
Juan Quintela |
Subject: |
Re: [Qemu-devel] [PATCH 0/5] VMState cleanups |
Date: |
Thu, 23 Feb 2012 14:52:42 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux) |
Alexander Graf <address@hidden> wrote:
> On 22.02.2012, at 17:09, Peter Maydell wrote:
>
>> On 22 February 2012 16:04, Andreas Färber <address@hidden> wrote:
>>> Am 22.02.2012 16:42, schrieb Peter Maydell:
>>>> On 22 February 2012 15:37, Andreas Färber <address@hidden> wrote:
>>>>> NB: Your cpu-vmstate patches were not applied so far and they appear to
>>>>> conflict with the plans we've made for redesigning cp15 on ARM: We want
>>>>> to convert today's static fields to some list and were hoping to have a
>>>>> mapping function for backwards compatibility. That works easiest in
>>>>> imperative code.
>>>>
>>>> I thought the idea for cp15 for vmstate was (like ppc) to basically
>>>> have a uint32_t cp15_regs[512] which we save/load the whole of, and
>>>> then the mapping function just assigns semantics to some subset
>>>> of that array? vmstate can do a plain array without problems.
>>>
>>> I thought we had concluded that the (3+3+4+4)² or so registers were too
>>> large for that so that Alex suggested to leave the old load/save in
>>> place (but getting/setting through a mapping function) and dynamically
>>> appending only the new cp15 registers we don't have fields for yet when
>>> some arrive. Or so I've understood.
>>
>> So what I thought Alex was suggesting was to nuke the existing
>> save/load, and instead we have this generic array. All the
>> current env->cp15.c1_scr &co turn from being uint32_t to uint32_t*,
>> and there's an init function per CPU which maps those to point at
>> slots in the cp15_regs[] array. Indexes into cp15_regs[] are
>> just arbitrary (though they can't change for a particular CPU
>> variant or you'd break migration).
>
> Yup. A nice side effect of this is that you have a known-small size of
> cp15_regs[]. But I suggested a lot of things during that discussion,
> so I quite frankly don't remember if that was the conclusion or just
> one idea ;)
I have to search that discussion, but I would like to send things as:
{ register_name, register value} array, otherwise inter-version
migration is just impossible (or very painful, that is similar).
Notice that this would also be very useful for x86 and MSR's. Just now
we send every MSR ad-hock with a new position.
Later, Juan.
- Re: [Qemu-devel] [PATCH 0/5] VMState cleanups, (continued)
- Re: [Qemu-devel] [PATCH 0/5] VMState cleanups, Peter Maydell, 2012/02/22
- Re: [Qemu-devel] [PATCH 0/5] VMState cleanups, Mitsyanko Igor, 2012/02/22
- Re: [Qemu-devel] [PATCH 0/5] VMState cleanups, Andreas Färber, 2012/02/22
- Re: [Qemu-devel] [PATCH 0/5] VMState cleanups, Juan Quintela, 2012/02/22
- Re: [Qemu-devel] [PATCH 0/5] VMState cleanups, Andreas Färber, 2012/02/22
- Re: [Qemu-devel] [PATCH 0/5] VMState cleanups, Peter Maydell, 2012/02/22
- Re: [Qemu-devel] [PATCH 0/5] VMState cleanups, Andreas Färber, 2012/02/22
- Re: [Qemu-devel] [PATCH 0/5] VMState cleanups, Peter Maydell, 2012/02/22
- Re: [Qemu-devel] [PATCH 0/5] VMState cleanups, Alexander Graf, 2012/02/22
- Re: [Qemu-devel] [PATCH 0/5] VMState cleanups,
Juan Quintela <=
Re: [Qemu-devel] [PATCH 0/5] VMState cleanups, Peter Maydell, 2012/02/22
- Prev by Date:
[Qemu-devel] [PATCH v1 1/1] ppc: Correctly define POWERPC_INSNS2_DEFAULT
- Next by Date:
[Qemu-devel] Sveltess, Veet Epilation, Zazie Coiffure, Esquisse Paris, Roc, Le Petit Marseillais , Ambi Pur, Air Wick, Febreze, Oust, Brise, S oftsheen Carson, Laboratoire 3 Chenes, Nivea, Déo Chez Bien-etre-prive.com
- Previous by thread:
Re: [Qemu-devel] [PATCH 0/5] VMState cleanups
- Next by thread:
Re: [Qemu-devel] [PATCH 0/5] VMState cleanups
- Index(es):