From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58393) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAQvx-0001TJ-0T for qemu-devel@nongnu.org; Wed, 21 Mar 2012 15:11:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SAQvv-0004fo-6Q for qemu-devel@nongnu.org; Wed, 21 Mar 2012 15:10:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61709) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAQvu-0004fc-VL for qemu-devel@nongnu.org; Wed, 21 Mar 2012 15:10:55 -0400 From: Juan Quintela In-Reply-To: <4F6A01F6.7000307@suse.de> ("Andreas =?utf-8?Q?F=C3=A4rber=22?= =?utf-8?Q?'s?= message of "Wed, 21 Mar 2012 17:29:42 +0100") References: <4F6A01F6.7000307@suse.de> Date: Wed, 21 Mar 2012 18:16:51 +0100 Message-ID: <87vclxeuws.fsf@elfo.elfo> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 24/36] vmstate: port arm cpu Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?utf-8?Q?F=C3=A4rber?= Cc: Peter Maydell , qemu-devel@nongnu.org, Paul Brook Andreas F=C3=A4rber wrote: > Am 19.03.2012 23:57, schrieb Juan Quintela: >> 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. >>=20 >> Introduce cpsr_vmstate field, as I am not sure if I can "use" >> uncached_cpsr for saving state. >>=20 >> Signed-off-by: Juan Quintela > > As stated previously, I still think we should hold off converting the > ARM CPU to VMState until the cp15 rework by Peter takes on shape. This converts all cpus to vmstate. Conversion of cp15 is indiferent of vmstate. Basically we will need to send something like one array of=20 pairs: [(register_id, value)], and have some validation before we receive it. Notice that something like that is also needed for x86 MSR's, just now we are sending them ad-hoc, but it would be great to do something like: - notice what msr's have been read/write by guest - just send that msr's. - maintain backwards compatibility is going to be a mess, but that don't affect arm at this moment. I guess that cp15 registers have some similar meaning (they are optional, and not all of them have been touched by the guest). But I still haven't a good idea on how to handle it. > On another matter, had you prefixed this patch with "target-arm: " > rather than hiding that essential keyword where my mailer cuts it off, > it would be much easier to find in this series than amidst lots of > "vmstate: " patches. clearly, we need: keywords in each patch, in the gmail sense. one patch can be related to several subsystems. general topic here was vmstate, but I fully agree that if I had used target-foo: as starting it would have been as good (just for a different definition of good). Thanks, Juan.