[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 08/10] Rework ram block hash

From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH 08/10] Rework ram block hash
Date: Tue, 19 May 2015 20:07:13 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

* Michael R. Hines (address@hidden) wrote:
> On 05/19/2015 01:55 PM, Dr. David Alan Gilbert wrote:
> >>I would like to keep the ramblock list directly addressable by hash
> >>on both sides, because, as I mentioned earlier, we want as much
> >>flexibility in registering RAMBlock memory as possible by being
> >>able to add or delete arbitrary blocks int the list at anytime during
> >>a migration.
> >>
> >>I will try to get the patchset that allows anyone to register memory
> >>for transfer out as soon as I can.
> >Hmm OK, I think I can rework that to regenerate the hash; it's a little
> >difficult without knowing how you're intending to use it.
> >
> >Dave
> We can use the RAMBlock name as a key to the hash, right?

Hmm, OK, I need to look at that; I guess some of those pointers are
constant once received.

> I see a "future" where storage replication also uses RDMA,
> (not that I'm volunteering to write it), but I don't want to
> lose the ability for arbitrary QEMU callers to be able to
> register/unregister ramblocks dynamically.

Yes, I'm going to try and wire RDMA up for COLO like you did
for the microcheckpoint work, so I can see the need to keep
it more general.

Let me go away and think about it; I think I can probably
keep the destination side hash, but it was just easier
to do it like this since it was unused.

If you do have code lieing around that uses it, please post
it and cc me and I can try and keep it so it looks like it might


> - Michae
Dr. David Alan Gilbert / address@hidden / Manchester, UK

reply via email to

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