qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 8/8] spapr_pci: Use XICS interrupt allocator


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH v2 8/8] spapr_pci: Use XICS interrupt allocator and do not cache interrupts in PHB
Date: Wed, 28 May 2014 13:35:40 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0


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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]