Am 31.01.2012 15:01, schrieb Mitsyanko Igor: > On 01/31/2012 05:15 PM, Andreas Färber wrote: >> Am 31.01.2012 00:53, schrieb Anthony Liguori: >>> On 01/30/2012 05:41 PM, Andreas Färber 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. (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 structs. >> 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 approach >> that I find promising. From my view, unofficially Juan is the VMState >> 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 workaround 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 uint32_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 > VMSTATE_BUFFER_MULTIPLY currently lacks VMS_POINTER flag and therefore > 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. -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
