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

[Tim Deegan <tim@xxxxxxx>]

At 13:29 -0400 on 13 Oct (1318512546), Adin Scannell wrote:
> 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.

Sounds sane to me.  If the handle/version is still globally unique then
this should work just fine.

As I think you said in a following email, for HVM guests the frame
numbers would have to be domid-gfn pairs rather than MFNs.  That makes
it a bit tricky if the original owner dies but other domains are sharing
the page.  Maybe nominate needs to return an MFN, but I don't like that
very much becuase it encourages tools writers to use MFNs with HVM
guests.

How about: keep the single opaque handle, but make it internally be MFN
(or rather, pdx) plus version, for a 128-bit ID?

Tim.

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