WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

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

<Prev in Thread] Current Thread [Next in Thread>