Re: [Xen-devel] [PATCH XEN v6 25/32] tools/libs/gnttab: Extensive updates to API documentation.

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Fri, 2015-12-11 at 17:35 +0000, Ian Campbell wrote:
> On Fri, 2015-12-11 at 17:19 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH XEN v6 25/32]
> > tools/libs/gnttab: Extensive updates to API documentation."):
> > > I'm currently intending to write something very similar for each of
> > > the
> > > xen*_open (gntshr, gnttab, foreignmemory, evtchn and probably call
> > > too)
> > > functions. I don't really like repeating the same thing like this,
> > > but
> > > I
> > > also don't really like API documentation which makes you play follow
> > > the
> > > piece of string to the docs of other libraries to find out what is
> > > going
> > > on.
> > 
> > That would be fine by me.ÂÂBut do these other functions suffer from
> > the same problem ?
> > 
> > Ie, can we for gntshr et al, tell the user that they should call
> > blah_unmap ?ÂÂThis is not practical in a multithreaded program for
> > hypercall memory but it might well be practical for other kinds of
> > borrowed memory.
> 
> Good point, I think most of the rest of them probably can support unmap
> after fork, but I'veÂnot checked (I will before I write anything).

Good thing I did.

On Linux both the gnttab and privcmd foreign mappings set VMA_DONTCOPY on
the mappings from the driver, which is the same effect as the
madvise(DONTFORK) in the hypercall buffer allocation has.

For gnttab this is obvious now I think about it, since you cannot unmap or
otherwise operate on a gntmap with normal PTE updates, you have to use
gntmap hypercalls, which core OS code like CoW handling obviously won't.

The same could be true for privcmd foreign mappings for PV guests, I think,
since the PTE update hypercall needs the foreign domid in it, which common
code wouldn't have.

So those memory regions simply won't exist in the child, and munmap would
therefore either fail or unmap whatever new thing has shown up at an
address.

So I think at least call, foreignmemory and gnttab need a
restriction/caveat like the above, which is that on fork but not exec you
can call close() and hope it does something, but unmap is off the table.

gntshr might be ok, although TBH I'm not really sure what the effect of
cow-wing memory which has been granted, nor how one ensures the desired
child/parent ends up with the actually granted memory and not a copy (IOW
it's not clear why VMA_DONTCOPY isn't applied here too). On that basis I'd
be inclined to give gntshr the same semantics as the others.

evtchn doesn't actually involve any memory mappings, and in that case
closing the fd is always fine and sufficient AFAICT, no need to disable
individual irqs first. I'm not entirely sure what the semantics of a poll
or read from both parent and child would be. I'm slightly inclined to
outlaw use in the child at the library API level. A slightly less draconian
rule would be one or the other may continue to use it, but never both.

That's all based on the Linux implementation, but the libraries need to be
LCD and so far that's pretty low... I looked at the FreeBSD privcmd, and it
didn't seem to have any obvious equivalent to VMA_DONTCOPY, but I might be
missing something (and it doesn't really matter for the library API given
Linux).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel