[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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?

Thanks,
Guanglin

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.