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.