Re: Re: Next steps with pv_ops for Xen

[Derek Murray <Derek.Murray@cl.cam.ac.uk>]

Stephen C. Tweedie wrote:
> So... the interface (a) cannot be used on the Linux VM without at least
> one invasive VM modification, due to the requirement of ptes being
> explicitly unmapped via hypercall;

Also there is the use of VM_FOREIGN 
(http://xenbits.xensource.com/linux-2.6.18-xen.hg?file/b2768401db94/mm/memory.c 
lines 1040--1059), which has been used quite happily in blktap since 
2005 
(http://lists.xensource.com/archives/html/xen-changelog/2005-07/msg00053.html). 
While it may not be a priority to get gntdev into pv-ops Linux, I should 
imagine that blktap would be fairly critical.

> I can't help wondering if this is a hint that now is the time to find a
> better API, which doesn't have the requirement (a) that seems to be
> causing such trouble?  Are other PV guests --- *BSD, Solaris --- going
> to have the same problems with their VM layers if they try to implement
> this API?  Upstream Linux pv_ops certainly will, and it would be good if
> we could avoid tying unprivileged guests to ABIs which cannot hope to be
> merged into pv_ops.

I'm open to suggestions... but I think it always reduces to needing a 
hook that is called on process exit before the PTEs are zapped.

> (Just what is the cost of not having this functionality in blktap,
> anyway?)

If tapdisk dies whilst holding a granted page, the page can never be 
ungranted, so we leak that page.

Regards,

Derek.