grant table anxiety [was RE: [Xen-devel] GNTTABOP_unmap_grant_ref]

["King, Steven R" <steven.r.king@xxxxxxxxx>]

Thank you guys and Muli for the thoughtful help.

I've aired grievances against grant tables in other threads, but now I'm
getting worried all over again.  Your suggestions give a hint of the
intricate handling required to manage shared pages.  IMHO, this pushes
paravirtual guests to unnatural lengths, not to mention prospects in
pure-virtual environments.

Could we dispense with these complexities if a 3rd party (Xen?) owned
shared pages?  If so, this adds impetus to get and try the memory
sharing patch Rusty has in waiting.

-steve


-----Original Message-----
From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
Sent: Wednesday, January 25, 2006 2:07 AM
To: King, Steven R
Cc: xen-devel; Muli Ben-Yehuda
Subject: Re: [Xen-devel] GNTTABOP_unmap_grant_ref


On 25 Jan 2006, at 01:33, King, Steven R wrote:

> To verify that I wasn't making some new mistake, inspection of 
> linux/mm/mmap.c shows that Linux calls vma->close() *after* the page 
> table manipulation.  In do_munmap(), the sequence is:
>
> detach_vmas_to_be_unmapped()
> unmap_region()       <--- page table manipulation buried in here
> remove_vma_list()    <--- vma->close() buried in here

As others have suggested, you need a special type of vma that knows how
to map/unmap/destruct ranges of granted mappings. A good way to do this
would be to have gnttab.c export a device file that has an mmap()
function. You can then add vma hook functions that know that any mapping
created in that vma range must be destructed via gnt_unmap operations.

> Is this turning into a Xen problem?  Why does Xen forbid implicit 
> unmapping of shared pages?

It's hard for Xen to distinguish between mappings created via grants vs.
mappings created because domain X is privileged to be able to map any
page of domain Y.

So far we've only really had grant-mapping code in the kernel. Doing it
in user space just needs some work on the clean-up path. We expect
guests to track and clean up their own mess. :-)

  -- Keir

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