Re: [Xen-devel] [PATCH RFC] memory sharing questions

[Adin Scannell <adin@xxxxxxxxxxxxxxx>]

Hi Tim,

> The handle isn't a count of how many times the page has been nominated,
> it's a global counter, incremented to be sure that the handles are
> unique.  The versioning avoids race conditions where the page gets
> unshared and re-shared.  Since the intended caller was the block
> backend, short-cutting a read from disk by sharing the last copy read,
> it's important that the mfn not have been unshared, changed and
> re-shared in the meantime.
>
> In the current system there's only one memory-sharing caller but there
> could easily be more, and it should be possible to recover from a
> crashed client too.
>
> AIUI the caller shouldn't have to be aware of the _meaning_ of the
> handle.  And there's no reason that the hash table couldn't be improved
> or replaced, if there's another way around the question of whether the
> page has changed since you last shared it.

Ah -- I understand.  This race condition (and the handle) makes sense
in the context of multiple callers. I still feel that the constant
storing and looking up of handles in a data structure is likely to be
problematic however (other than possibly a simple list for
debugging/audit).  What if the interface were changed to something
like the following:

handle_t mem_sharing_nominate(mfn_t mfn);
int mem_sharing_page_share(mfn_t one, handle_t one_version, mfn_t two,
handle_t two_handle);

In this case, the handle can be the same global counter as per before,
except it can be stored in a saved structure alongside the associated
domain gfns and used only for a safety check. When calling
mem_sharing_page_share, xen would no longer need to lookup a handle in
a data structure -- but could still enforce the check that the version
matches and avoid the nominate, unshare, nominate (by someone else)
race condition.

I believe that caller would still store the same amount of
information, it would just pass down the mfns as well as the handle /
version.

Thoughts?

Cheers!
-Adin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel