[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/5] VMState cleanups
From: |
Alexander Graf |
Subject: |
Re: [Qemu-devel] [PATCH 0/5] VMState cleanups |
Date: |
Thu, 23 Feb 2012 00:41:22 +0100 |
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 ;)
Alex
- [Qemu-devel] [PATCH 5/5] vmstate: introduce get_bufsize entry in VMStateField, (continued)
- [Qemu-devel] [PATCH 5/5] vmstate: introduce get_bufsize entry in VMStateField, Igor Mitsyanko, 2012/02/22
- 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 <=
- Re: [Qemu-devel] [PATCH 0/5] VMState cleanups, Juan Quintela, 2012/02/23
Re: [Qemu-devel] [PATCH 0/5] VMState cleanups, Peter Maydell, 2012/02/22