From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43035) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0Z6R-0002PM-6o for qemu-devel@nongnu.org; Thu, 23 Feb 2012 08:53:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S0Z6L-0005co-88 for qemu-devel@nongnu.org; Thu, 23 Feb 2012 08:52:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:30521) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0Z6L-0005cj-1U for qemu-devel@nongnu.org; Thu, 23 Feb 2012 08:52:53 -0500 From: Juan Quintela In-Reply-To: <5AC8EC71-6172-4A54-8A8D-F84E2771DD1E@suse.de> (Alexander Graf's message of "Thu, 23 Feb 2012 00:41:22 +0100") References: <1329905754-11873-1-git-send-email-i.mitsyanko@samsung.com> <87d397ufsh.fsf@elfo.elfo> <4F450BD3.3010909@suse.de> <4F45121D.6050806@suse.de> <5AC8EC71-6172-4A54-8A8D-F84E2771DD1E@suse.de> Date: Thu, 23 Feb 2012 14:52:42 +0100 Message-ID: <87d395u05x.fsf@elfo.elfo> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/5] VMState cleanups Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Peter Maydell , Igor Mitsyanko , e.voevodin@samsung.com, qemu-devel@nongnu.org, kyungmin.park@samsung.com, d.solodkiy@samsung.com, anthony@codemonkey.ws, m.kozlov@samsung.com, Andreas =?utf-8?Q?F=C3=A4rb?= =?utf-8?Q?er?= , Paul Brook Alexander Graf wrote: > On 22.02.2012, at 17:09, Peter Maydell wrote: > >> On 22 February 2012 16:04, Andreas F=C3=A4rber wrote: >>> Am 22.02.2012 16:42, schrieb Peter Maydell: >>>> On 22 February 2012 15:37, Andreas F=C3=A4rber wrot= e: >>>>> 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 wa= nt >>>>> 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. >>>>=20 >>>> 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. >>>=20 >>> I thought we had concluded that the (3+3+4+4)=C2=B2 or so registers wer= e 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. >>=20 >> 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.