Re: [Xen-devel] [PATCH 10 of 24] libxc: infrastructure for hypercall safe data buffers

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("Re: [Xen-devel] [PATCH 10 of 24] libxc: infrastructure 
for hypercall safe data buffers"):
> It's not clear what phase 2 actually is (although phase 3 is clearly
> profit), I don't think any existing syscalls do what we need. mlock
> (avoiding the stack) gets pretty close and so far the issues with mlock
> seem to have been more potential than hurting us in practice, but it
> pays to be prepared e.g. for more aggressive page migration/coalescing
> in the future, I think.

Ian and I discussed this extensively on IRC, during which conversation
I became convinced that mlock() must do what we want.  Having read the
code in the kernel I'm not not so sure.

The ordinary userspace access functions are all written to cope with
pagefaults and retry the access.  So userspace addresses are not in
general valid in kernel mode even if you've called functions to try to
test them.  It's not clear what mlock prevents; does it prevent NUMA
page migration ?  If not then I think indeed the page could be made
not present by one VCPU editing the page tables while another VCPU is
entering the hypercall, so that the 2nd VCPU will get a spurious
EFAULT.

OTOH: there must be other things that work like Xen - what about user
mode device drivers of various kinds ?  Do X servers not mlock memory
and expect to be able to tell the video card to DMA to it ?  etc.
I think if linux-kernel think that people haven't assumed that mlock()
actually pins the page, they're mistaken - and it's likely to be not
just us.

Ian.

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