From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:60164)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <afaerber@suse.de>) id 1SXDcJ-0002Ev-Vr
	for qemu-devel@nongnu.org; Wed, 23 May 2012 11:36:57 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <afaerber@suse.de>) id 1SXDcB-0003zu-FA
	for qemu-devel@nongnu.org; Wed, 23 May 2012 11:36:51 -0400
Received: from cantor2.suse.de ([195.135.220.15]:51782 helo=mx2.suse.de)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <afaerber@suse.de>) id 1SXDcB-0003zA-6M
	for qemu-devel@nongnu.org; Wed, 23 May 2012 11:36:43 -0400
Message-ID: <4FBD0400.90101@suse.de>
Date: Wed, 23 May 2012 17:36:32 +0200
From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= <afaerber@suse.de>
MIME-Version: 1.0
References: <1337742502-28565-1-git-send-email-afaerber@suse.de>
	<alpine.DEB.2.00.1205231225510.26786@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1205231225510.26786@kaball-desktop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH qom-next 00/59] QOM CPUState,
	part 4: CPU_COMMON
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

Am 23.05.2012 13:27, schrieb Stefano Stabellini:
> On Wed, 23 May 2012, Andreas F=C3=A4rber wrote:
>> This series, based on qom-next and the two pending ARM cleanup patches=
, starts
>> moving fields from CPUArchState (CPU_COMMON) to QOM CPUState. It stops=
 short
>> of moving all easily possible fields (i.e., those not depending on tar=
get_ulong
>> or target_phys_addr_t) since the series got too long already and is ex=
pected to
>> spark some controversies due to collisions with several other series.
>>
>> The series is structured as preparatory refactorings interwoven with t=
he actual
>> touch-all movement of one field ("cpu: Move ... to CPUState"), optiona=
lly
>> followed by type signature cleanups, culminating in the movement of tw=
o fields
>> that are tied together by VMState.
>> Thus, unlike part 3, this series cannot randomly be cherry-picked to
>> <arch>-next trees, only select parts thereof (e.g., use of cpu_s390x_i=
nit()).
>>
>> Please review and test.
[...]
>> I have checked this to compile on ...
>> * openSUSE 12.1 x86_64 w/KVM,
>> * openSUSE Factory ppc w/KVM,
>> * SLES 11 SP2 s390x w/KVM,
>> * mingw32/64 cross-builds,
>> * OpenBSD 5.1 amd64 (not for final version though, master doesn't buil=
d).
>> Untested: Xen.
>=20
> I tested it on Xen: it works correctly.
>=20
> Tested-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Thanks for the quick response! I've cherry-picked the preparatory patch
to qom-next:
http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-next

/-F

--=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