Re: [Xen-users] BUG : privcmd mmap 160+ pages

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2013-07-29 at 16:16 -0400, Guanglin Xu wrote:
> Hi all,
> 
> I just find a xc_map_foreign_range() problem in Xen.
> 
> xc_map_foreign_range(), an API of libxc backed by privcmd - a xen
> kernel module, can be used to mmap guest VM memory into dom0. However,
> if we mmap more than 160 pages, we'll fail.
> 
> Inside xc_map_foreign_range(), it uses ioctrl to communicate with
> privcmd. There are 2 ioctl commands, the one is
> IOCTL_PRIVCMD_MMAPBATCH (legacy), another one is
> IOCTL_PRIVCMD_MMAPBATCH_V2 (newer). Both of them constantly return 0
> (success), but the mmapings are fail after mmaping 160 pages.
> 
> Firstly, when my Linux kernel version was 3.5, IOCTL_PRIVCMD_MMAPBATCH
> was the only one ioctl command.  rc = ioctl(fd,
> IOCTL_PRIVCMD_MMAPBATCH, &ioctlx).  After mapping 160 pages, the
> subsequent invoking of ioctl would
> set ioctlx.arr[] items to 140737344202616, overwriting the original
> pfn number.
> 
> And then, I updated my Linux kernel to 3.8 so as to test
> IOCTL_PRIVCMD_MMAPBATCH_V2. rc = ioctl(fd,
> IOCTL_PRIVCMD_MMAPBATCH_V2, &ioctlx). This time, the post-160 invoking
> of ioctl would set ioctls.err[] items to EINVAL.
> 
> Although I have inserted printk() in privcmd.c to track its execution
> flow, the result showed a look-like complete path, which is quite
> weird. I have no idea what happened in privcmd.
> 
> Can anyone figure out this problem?

I wouldn't be all that surprised if there was a hardcoded batch size
limit somewhere in either libxc or the privcmd driver.

If you map you memory in batch of e.g. 128 pages does it all work OK?

If you want to get to the bottom of the 160 page limit you'll probably
have to trace through the code looking for hardcoded sizes or limits on
sizes (e.g. of arrays) or perhaps integer indexes etc which are too
small and are overflowing.

160 * the size of the various structs involved doesn't look to be all
that interesting (i.e. just over a page size boundary or something), but
that's the sort of direction I would start by looking in.

If you can't spot it by eye then you'll likely have to instrument the
code paths with prints to try and track the progress of the initially
supplied buffer through to the hypercall etc.

Ian.



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