From mboxrd@z Thu Jan 1 00:00:00 1970 From: Igor Mitsyanko Subject: Re: [Qemu-devel] KVM call agenda for tuesday 31 Date: Thu, 09 Aug 2012 11:53:30 +0400 Message-ID: <50236C7A.1090600@samsung.com> References: <87ehuhrpel.fsf@elfo.elfo> <4F272A92.2010609@suse.de> <4F272D8C.8020608@codemonkey.ws> <4F27E98E.2080501@suse.de> <4F27F436.9020801@samsung.com> <502292EF.3010202@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: quintela@redhat.com, Anthony Liguori , KVM devel mailing list , Developers qemu-devel , Dmitry Solodkiy , Jason Baron , Alexander Graf To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Return-path: Received: from mailout2.w1.samsung.com ([210.118.77.12]:32480 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756127Ab2HIHxe (ORCPT ); Thu, 9 Aug 2012 03:53:34 -0400 Received: from eusync3.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by mailout2.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0M8H00AU29XYUQ40@mailout2.w1.samsung.com> for kvm@vger.kernel.org; Thu, 09 Aug 2012 08:53:58 +0100 (BST) Received: from [106.109.9.232] by eusync3.samsung.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPA id <0M8H002XO9X6V170@eusync3.samsung.com> for kvm@vger.kernel.org; Thu, 09 Aug 2012 08:53:31 +0100 (BST) In-reply-to: <502292EF.3010202@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On 08/08/2012 08:25 PM, Andreas F=C3=A4rber wrote: > Am 31.01.2012 15:01, schrieb Mitsyanko Igor: >> On 01/31/2012 05:15 PM, Andreas F=C3=A4rber wrote: >>> Am 31.01.2012 00:53, schrieb Anthony Liguori: >>>> On 01/30/2012 05:41 PM, Andreas F=C3=A4rber 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 a= nd >>>>> that >>>>> patches should not be deferred until the merge. Yet there's no re= view >>>>> 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 wit= h >>> subsets of arrays embedded within the struct and variable-sized lis= t of >>> pointers to structs but no solution for a malloc()'ed array of stru= cts. >>> Maybe I'm just too stupid to see. Anyway, no one commented since Xm= as. >>> >>> Igor posted (and refined for v2) a patch with a callback-based appr= oach >>> that I find promising. From my view, unofficially Juan is the VMSta= te >>> guy, he's been cc'ed. Are we lacking an official maintainer that ca= res? >>> Or is Juan the official, undocumented maintainer but simply busy? >>> >>> SUSE's interest is making AHCI migratable, and my VMState workaroun= d for >>> that is simply ugly: >>> >>> http://patchwork.ozlabs.org/patch/133066/ (RFC) >>> >> If I'm not mistaken, if you change AHCIState's ".ports" type to uint= 32_t >> you can use existing VMSTATE_BUFFER_MULTIPLY macro like this: >> >> VMSTATE_BUFFER_MULTIPLY(dev, AHCIState, 0, NULL, 0, ports, >> sizeof(AHCIDevice)) > Igor, I finally got around to rebasing and trying this: Am I seeing > correctly that this tries to serialize the whole of AHCIDevice as an > opaque buffer? The difficulty here was that we were looking for a way= to > serialize a variable number of structured elements with their own > &vmstate_ahci_device specifying what fields to serialize. > > Juan, how should we proceed there? Do as Igor suggested? Some VMSTATE= _ > macro I'm overlooking? Or do we need some new macro for this use case= ? > > Regards, > Andreas Hi Andreas, that was a bad suggestion, sorry for that, we can't treat=20 structures as opaque buffers because that wouldn't work when migrating=20 between hosts with different alignment/endianess. Perhaps you can use VMSTATE_STRUCT_VARRAY_UINT32 for this, if I'm not=20 again mistaken. >> VMSTATE_BUFFER_MULTIPLY currently lacks VMS_POINTER flag and therefo= re >> doesn't make any use of _start field (you don't need it anyway) >> >> Nevertheless, VMSTATE_BUFFER_MULTIPLY is just a partial solution to = a >> bigger set of possible problems. SD card's vmstate implementation >> requires shift operation, SDHC gets size from switch {} statement, >> something else later may require division or addition e.t.c., >> get_bufsize callback will cover all possible cases. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54729) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SzNYm-0007xp-P6 for qemu-devel@nongnu.org; Thu, 09 Aug 2012 03:53:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SzNYl-0007ec-Fy for qemu-devel@nongnu.org; Thu, 09 Aug 2012 03:53:36 -0400 Received: from mailout1.w1.samsung.com ([210.118.77.11]:26709) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SzNYl-0007eQ-AD for qemu-devel@nongnu.org; Thu, 09 Aug 2012 03:53:35 -0400 Received: from eusync3.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) by mailout1.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0M8H00HQX9XZCO40@mailout1.w1.samsung.com> for qemu-devel@nongnu.org; Thu, 09 Aug 2012 08:53:59 +0100 (BST) Received: from [106.109.9.232] by eusync3.samsung.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPA id <0M8H002XO9X6V170@eusync3.samsung.com> for qemu-devel@nongnu.org; Thu, 09 Aug 2012 08:53:31 +0100 (BST) Date: Thu, 09 Aug 2012 11:53:30 +0400 From: Igor Mitsyanko In-reply-to: <502292EF.3010202@suse.de> Message-id: <50236C7A.1090600@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE References: <87ehuhrpel.fsf@elfo.elfo> <4F272A92.2010609@suse.de> <4F272D8C.8020608@codemonkey.ws> <4F27E98E.2080501@suse.de> <4F27F436.9020801@samsung.com> <502292EF.3010202@suse.de> Subject: Re: [Qemu-devel] KVM call agenda for tuesday 31 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Cc: KVM devel mailing list , quintela@redhat.com, Jason Baron , Developers qemu-devel , Alexander Graf , Dmitry Solodkiy , Anthony Liguori On 08/08/2012 08:25 PM, Andreas F=C3=A4rber wrote: > Am 31.01.2012 15:01, schrieb Mitsyanko Igor: >> On 01/31/2012 05:15 PM, Andreas F=C3=A4rber wrote: >>> Am 31.01.2012 00:53, schrieb Anthony Liguori: >>>> On 01/30/2012 05:41 PM, Andreas F=C3=A4rber 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= and >>>>> that >>>>> patches should not be deferred until the merge. Yet there's no = review >>>>> 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. (Ale= x >>> mentioned it on one call around November.) I found ways to deal w= ith >>> subsets of arrays embedded within the struct and variable-sized l= ist of >>> pointers to structs but no solution for a malloc()'ed array of st= ructs. >>> Maybe I'm just too stupid to see. Anyway, no one commented since = Xmas. >>> >>> Igor posted (and refined for v2) a patch with a callback-based ap= proach >>> that I find promising. From my view, unofficially Juan is the VMS= tate >>> guy, he's been cc'ed. Are we lacking an official maintainer that = cares? >>> Or is Juan the official, undocumented maintainer but simply busy? >>> >>> SUSE's interest is making AHCI migratable, and my VMState workaro= und for >>> that is simply ugly: >>> >>> http://patchwork.ozlabs.org/patch/133066/ (RFC) >>> >> If I'm not mistaken, if you change AHCIState's ".ports" type to ui= nt32_t >> you can use existing VMSTATE_BUFFER_MULTIPLY macro like this: >> >> VMSTATE_BUFFER_MULTIPLY(dev, AHCIState, 0, NULL, 0, ports, >> sizeof(AHCIDevice)) > Igor, I finally got around to rebasing and trying this: Am I seeing > correctly that this tries to serialize the whole of AHCIDevice as a= n > opaque buffer? The difficulty here was that we were looking for a w= ay to > serialize a variable number of structured elements with their own > &vmstate_ahci_device specifying what fields to serialize. > > Juan, how should we proceed there? Do as Igor suggested? Some VMSTA= TE_ > macro I'm overlooking? Or do we need some new macro for this use ca= se? > > Regards, > Andreas Hi Andreas, that was a bad suggestion, sorry for that, we can't treat= =20 structures as opaque buffers because that wouldn't work when migratin= g=20 between hosts with different alignment/endianess. Perhaps you can use VMSTATE_STRUCT_VARRAY_UINT32 for this, if I'm not= =20 again mistaken. >> VMSTATE_BUFFER_MULTIPLY currently lacks VMS_POINTER flag and there= fore >> doesn't make any use of _start field (you don't need it anyway) >> >> Nevertheless, VMSTATE_BUFFER_MULTIPLY is just a partial solution t= o a >> bigger set of possible problems. SD card's vmstate implementation >> requires shift operation, SDHC gets size from switch {} statement, >> something else later may require division or addition e.t.c., >> get_bufsize callback will cover all possible cases.