| |
|
 |
|
 |
|
|
|
| |
|
|
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
|
|
|
| |
|
Home