Re: Re: Next steps with pv_ops for Xen

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

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?

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

>> I think this would represent good progress, though I wonder if there
>> would be a performance penalty due to performing the mapping and
>> unmapping in user-space (multiple syscalls per mapping versus a single
>> hypercall).
> 
> I'd expect the hard disk (and how I/O is scheduled) being the
> bottleneck, not the syscall overhead.  Nevertheless I plan to benchmark
> it once I have it up and running.

Great to hear that you're working on this! Let me know if there's any 
other help I can provide with gntdev.

Cheers,

Derek.