From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58931) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0Ega-00067o-Q2 for qemu-devel@nongnu.org; Wed, 22 Feb 2012 11:05:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S0EgT-0002cO-07 for qemu-devel@nongnu.org; Wed, 22 Feb 2012 11:04:56 -0500 Received: from cantor2.suse.de ([195.135.220.15]:35282 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0EgS-0002c6-OD for qemu-devel@nongnu.org; Wed, 22 Feb 2012 11:04:48 -0500 Message-ID: <4F45121D.6050806@suse.de> Date: Wed, 22 Feb 2012 17:04:45 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1329905754-11873-1-git-send-email-i.mitsyanko@samsung.com> <87d397ufsh.fsf@elfo.elfo> <4F450BD3.3010909@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/5] VMState cleanups List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Igor Mitsyanko , e.voevodin@samsung.com, quintela@redhat.com, qemu-devel@nongnu.org, Alexander Graf , kyungmin.park@samsung.com, d.solodkiy@samsung.com, m.kozlov@samsung.com, Paul Brook Am 22.02.2012 16:42, schrieb Peter Maydell: > On 22 February 2012 15:37, Andreas F=C3=A4rber wrote= : >> NB: Your cpu-vmstate patches were not applied so far and they appear t= o >> conflict with the plans we've made for redesigning cp15 on ARM: We wan= t >> 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. I thought we had concluded that the (3+3+4+4)=C2=B2 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. I was planning some cp15 coding once I've moved some more stuff out of CPU_COMMON and resolved the pxa270 CPU classes mess. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg