On 08/08/2012 08:25 PM, Andreas Färber wrote:
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
Hi Andreas, that was a bad suggestion, sorry for that, we can't treat
structures as opaque buffers because that wouldn't work when migrating
between hosts with different alignment/endianess.
Perhaps you can use VMSTATE_STRUCT_VARRAY_UINT32 for this, if I'm not
again mistaken.
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.
--
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
