Re: [Qemu-ppc] [PATCH v2 8/8] spapr_pci: Use XICS interrupt allocator and do not cache interrupts in PHB

[Alexander Graf]

On 28.05.14 03:18, Alexey Kardashevskiy wrote:
> On 05/28/2014 10:41 AM, Alexander Graf wrote:
> > On 28.05.14 02:34, Alexey Kardashevskiy wrote:
> > > On 05/28/2014 09:55 AM, Alexander Graf wrote:

...

> > > > How do I migrate GHashTable? If I am allowed to use custom and bit more
> > > > polished get/put from "[PATCH 1/2] vmstate: Add helper to enable
> > > > GHashTable
> > > > migration", I'll be fine.
> > > > Yeah, I think it's ok to be custom in this case. Or another crazy idea -
> > > > could you flatten the hash table into an array of structs that you can
> > > > describe using VMState? You could then convert from the flat array to/from
> > > > the GHashTable with pre_load/post_load hooks.
> > > Array is exactly what I am trying to get rid of. Ok, I'll remove hashmap at
> > > all and implement dynamic flat array (yay, yet another bicycle!).
> > Huh? The array would only live during the migration. It would be size=0
> > during normal execution, but in a pre_save hook we could make size =
> > hash.length() and reuse the existing, working VMState infrastructure.
> When would I free that array? What if I continue the source guest and then
> migrate again?

Something like

void pre_save(...) {
    free(s->array);
    s->array_len = s->hash.number_of_keys();
    s->array = g_malloc(s->array_len * sizeof(struct array_elem));
    for (i = 0; i < s->array_len; i++) {
        s->array[i].key = s->hash.key[i];
        s->array[i].value = s->hash.value[i];
    }
}

That would waste a few bytes when we continue after migration, but it 
should at least keep that overhead to a minimum.

> I mean I can solve all of this for sure but duplicating data
> just to make existing migration happy is bit weird. But - I'll do what you
> say here, it is no big deal :)

I don't find the concept of duplicating data for migration too odd - it 
sounds like a good compromise between introspectability and abstraction. 
If you have a better suggestion I'm all open :).


Alex