From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60436) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsFMA-00029M-Mz for qemu-devel@nongnu.org; Tue, 31 Jan 2012 10:10:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RsFM9-00019d-4V for qemu-devel@nongnu.org; Tue, 31 Jan 2012 10:10:50 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45063) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsFM8-00019S-U1 for qemu-devel@nongnu.org; Tue, 31 Jan 2012 10:10:49 -0500 Date: Tue, 31 Jan 2012 17:10:46 +0200 From: "Michael S. Tsirkin" Message-ID: <20120131151045.GA3000@redhat.com> References: <87ehuhrpel.fsf@elfo.elfo> <4F272A92.2010609@suse.de> <4F272D8C.8020608@codemonkey.ws> <4F27E98E.2080501@suse.de> <4F27F6CD.1000807@codemonkey.ws> <20120131150447.GA2899@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20120131150447.GA2899@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] KVM call agenda for tuesday 31 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Developers qemu-devel , Mitsyanko Igor , Andreas =?iso-8859-1?Q?F=E4rber?= , KVM devel mailing list , quintela@redhat.com On Tue, Jan 31, 2012 at 05:04:48PM +0200, Michael S. Tsirkin wrote: > On Tue, Jan 31, 2012 at 08:12:29AM -0600, Anthony Liguori wrote: > > On 01/31/2012 07:15 AM, Andreas F=E4rber wrote: > > >Am 31.01.2012 00:53, schrieb Anthony Liguori: > > >>On 01/30/2012 05:41 PM, Andreas F=E4rber wrote: > > >>>Am 30.01.2012 19:55, schrieb Juan Quintela: > > >>>>Please send in any agenda items you are interested in covering. > > > > > >>>VMState: > > >>>Anthony specifically said that VMState were not affected by QOM an= d that > > >>>patches should not be deferred until the merge. Yet there's no rev= iew > > >>>and/or decision-making for a month now. Ping^2 for AHCI+SDHC. > > >> > > >>Do you have pointers (to pending VMState patches)? > > > > > >http://patchwork.ozlabs.org/patch/137732/ (PATCH v4) > > > > > >It's basically about how to deal with variable-sized arrays. (Alex > > >mentioned it on one call around November.) I found ways to deal with > > >subsets of arrays embedded within the struct and variable-sized list= of > > >pointers to structs but no solution for a malloc()'ed array of struc= ts. > > >Maybe I'm just too stupid to see. Anyway, no one commented since Xma= s. > >=20 > > /me puts on his flame proof suit > >=20 > > Don't use VMState. Just open code a save/restore function. VMState > > is too limited in how it handles complex data structures. > >=20 > > I really believe the only long term solution we're going to get to > > here is something that uses a builder interface (like Visitors). > >=20 > > Regards, > >=20 > > Anthony Liguori >=20 > So the TPM patches started implementing a visitor interface > for BER, they are still blocked, right? And by the way, I believe we really should switch to something like BER and just drop the legacy migration format - being non self delimiting makes it just too painful for words to abstract, and attempts to hide that mess behind a visitor interface will just cause more cruft to accumulate, and cause inefficiencies such as extra data copies. > > > > > >Igor posted (and refined for v2) a patch with a callback-based appro= ach > > >that I find promising. From my view, unofficially Juan is the VMStat= e > > >guy, he's been cc'ed. Are we lacking an official maintainer that car= es? > > >Or is Juan the official, undocumented maintainer but simply busy? > > > > > >SUSE's interest is making AHCI migratable, and my VMState workaround= for > > >that is simply ugly: > > > > > >http://patchwork.ozlabs.org/patch/133066/ (RFC) > > > > > >Therefore I'm waiting for some resolution. > > > > > >Regards, > > >Andreas > > > > >=20 > > -- > > To unsubscribe from this list: send the line "unsubscribe kvm" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html