Re: Re: Next steps with pv_ops for Xen

[Ian Main <imain@redhat.com>]

On Tue, 04 Dec 2007 09:40:49 +0000
Derek Murray <Derek.Murray@cl.cam.ac.uk> wrote:

> Gerd Hoffmann wrote:
> >> On this point I completely agree with you! If anyone has any less
> >> radical suggestions, then I'd be delighted to refactor the gntdev code
> >> to use them. However, I'm not currently aware of any alternative that
> >> maintains robustness to process crashes.
> > 
> > Oh, for me it isn't robust at all, it crashes on the first munmap
> > syscall.  It is the Fedora 8 kernel.  See attachment.  Didn't try
> > xensource 2.6.18 yet.
> 
> My gut feeling is that something changed in mm between 2.6.18 and 
> 2.6.21, but that seems like a cop out so...
> 
> > Ideas what is wrong?
> 
> Since the bug appears to be in page_remove_rmap, that would tend to 
> imply that there is never a corresponding page_add_*_rmap 
> (page_add_file_rmap?). My knowledge of the Linux mm code is a bit shaky 
> here: should gntdev be doing this? Should we be using install_page (or a 
> modified version thereof) to set the PTE?
> 
> Also, does a simple program that opens gntdev, maps a grant, 
> accesses/writes to the page, and unmaps it (all using the xc_gnttab_* 
> functions) work?

I am part of a team working on a project with Intel that is using it a
fair bit in a number of places.

We actually have no such simple test right now that I'm aware of,
but we are certainly using it in larger applications and it does work.
The only problem we're seeing is that killed processes using it cause a
BUG to fire.  I haven't explored it more than that yet, and I can't say
for sure that gntdev is causing that either as it's a complex program
(although I'm not aware of anything else in there that might cause it).

> > Who uses the gntdev device right now?
> 
> Good question! I'm aware of it being used in a few research projects, 
> and it seems to work for them (though I think it is mostly used with the 
> linux-2.6.18-xen kernel). Anyone else?

We are using it with 2.6.18 xen kernel.

    Ian