[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] BUG : privcmd mmap 160+ pages
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |