一句话描述： xen hypercall 在应用层的实现，最终都变成对
/proc/xen/privcmd 的 ioctl 系统调用
我们知道，xen 在应用层最上层的接口是 libxl , 基本上所以应用程序对xen的操作都通过 libxl 提供的API实现。 这里我们也从 libxl
入口探讨 hypercall 的实现，主要涉及的是 libxl context 初始化部分。所有的xl 调用，如 xl create/ xl list/ xl
destroy 都会创建一个上下文环境，这个上下文环境对所有 Xl 进程都是一致的（所以才能叫 context 嘛），什么意思呢 ？ 比如你在一台设备上调用多次
Xl create 启动多台虚拟机，那么这多个xl 进程共享一个context , 这究竟是怎么实现的
？一般，跨进程的context实现，就是在应用层维护一个基于共享内存的控制结构，当然要辅助各种同步机制，libxl
的上下文没有这么复杂，因为它本质上不是在应用层维护的，而是在domain0的内核维护的，为什么这么说呢？ 看下面xl 初始化代码：
libxl/xl.c
int main(int argc, char **argv)
{
。。。。。。。
xl_ctx_alloc(); // xl 的main函数，初始化context
。。。。
}libxl/libxl.c
int libxl_ctx_alloc(libxl_ctx **pctx, int version,
unsigned flags, xentoollog_logger * lg)
{
libxl_ctx *ctx = NULL;
struct stat stat_buf;
int rc;if (version != LIBXL_VERSION) { rc = ERROR_VERSION; goto out; }
ctx = malloc(sizeof(*ctx));
memset(ctx, 0, sizeof(libxl_ctx));
ctx->lg = lg;/* First initialise pointers etc. (cannot fail) */
ctx->nogc_gc.alloc_maxsize = -1;
ctx->nogc_gc.owner = ctx;LIBXL_TAILQ_INIT(&ctx->occurred);
ctx->osevent_hooks = 0;
LIBXL_LIST_INIT(&ctx->pollers_event);
LIBXL_LIST_INIT(&ctx->pollers_idle);LIBXL_LIST_INIT(&ctx->efds);
LIBXL_TAILQ_INIT(&ctx->etimes);ctx->watch_slots = 0;
LIBXL_SLIST_INIT(&ctx->watch_freeslots);
libxl__ev_fd_init(&ctx->watch_efd);LIBXL_TAILQ_INIT(&ctx->death_list);
libxl__ev_xswatch_init(&ctx->death_watch);ctx->childproc_hooks = &libxl__childproc_default_hooks;
ctx->childproc_user = 0;ctx->sigchld_selfpipe[0] = -1;
/* The mutex is special because we can‘t idempotently destroy it */
if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
free(ctx);
ctx = 0;
}
rc = libxl__atfork_init(ctx);
if (rc) goto out;rc = libxl__poller_init(ctx, &ctx->poller_app);
if (rc) goto out;if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
"failed to stat %s", XENSTORE_PID_FILE);
rc = ERROR_FAIL; goto out;
}ctx->xch = xc_interface_open(lg,lg,0); // 获取 xc 控制接口
if (!ctx->xch) {
LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, errno,
"cannot open libxc handle");
rc = ERROR_FAIL; goto out;
}ctx->xsh = xs_daemon_open(); // 获取 xs 控制接口
if (!ctx->xsh)
ctx->xsh = xs_domain_open();
if (!ctx->xsh) {
LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, errno,
"cannot connect to xenstore");
rc = ERROR_FAIL; goto out;
}*pctx = ctx;
return 0;
}
可以看到， xl 的main函数里会调用 xl_ctx_alloc, 后者的具体实现在 libxl_ctx_alloc 函数里，这个函数除了初始化一堆
list 和 tailq 之外，有实质性的调用是 xc_interface_open 和 xs_daemon_open ， 即获取对 xc 接口和
xs 接口的控制体，而这两种控制结构的获取最终都是通过打开文件系统获取某个fd来实现,
我们知道，文件系统是kernel维护的，所以说，libxl
的上下文环境更确切说是在 domain0 的 kernel 内部维护的。其中 ，xc 接口主要对应各种hypercall , xs 接口主要对应
xenstore 共享内存机制和事件机制。这里先不管xenstore机制，因为xen hypercall主要涉及的是xc接口的实现。
xc_interface_open的具体实现在 xc_interface_open_common：
// libxc/xc_private.c
static struct xc_interface_core *xc_interface_open_common(xentoollog_logger *logger,
xentoollog_logger *dombuild_logger,
unsigned open_flags,
enum xc_osdep_type type)
{
。。。。。
xch = malloc(sizeof(*xch));
if (!xch) {
xch = &xch_buf;
PERROR("Could not allocate new xc_interface struct");
goto err;
}
*xch = xch_buf;if (!(open_flags & XC_OPENFLAG_DUMMY)) {
if ( xc_osdep_get_info(xch, &xch->osdep) < 0 ) // 打开动态库文件并获取符号地址
goto err;xch->ops = xch->osdep.init(xch, type);// 调用xc控制器的初始化函数，获取真正的xc 控制结构
if ( xch->ops == NULL )
{
DPRINTF("OSDEP: interface %d (%s) not supported on this platform",
type, xc_osdep_type_name(type));
goto err_put_iface;
}xch->ops_handle = xch->ops->open(xch);// 调用 xc 控制结构的open函数获取 ioctl 作用的 fd 文件描述符
if (xch->ops_handle == XC_OSDEP_OPEN_ERROR)
goto err_put_iface;
}return xch;
}
static int xc_osdep_get_info(xc_interface *xch, xc_osdep_info_t *info)
{
int rc = -1;
const char *lib = getenv(XENCTRL_OSDEP);// 获取环境变量的值，该值执行 libxc 动态链接库文件位置
xc_osdep_info_t *pinfo;
void *dl_handle = NULL;if ( lib != NULL )
{
if ( getuid() != geteuid() )
{
if ( xch ) ERROR("cannot use %s=%s with setuid application", XENCTRL_OSDEP, lib);
abort();
}
if ( getgid() != getegid() )
{
if ( xch ) ERROR("cannot use %s=%s with setgid application", XENCTRL_OSDEP, lib);
abort();
}dl_handle = dlopen(lib, RTLD_LAZY|RTLD_LOCAL);// dlopen动态加载 libxl 动态库文件
if ( !dl_handle )
{
if ( xch ) ERROR("unable to open osdep library %s: %s", lib, dlerror());
goto out;
}pinfo = dlsym(dl_handle, "xc_osdep_info");// dlsym 获取符号 xc_osdep_info
if ( !pinfo )
{
if ( xch ) ERROR("unable to find xc_osinteface_info in %s: %s", lib, dlerror());
goto out;
}*info = *pinfo;
info->dl_handle = dl_handle;
}
}
我们看到，xc_interface_open_common的实现是打开环境变量 XENCTRL_OSDEP
指向的动态库文件，并dlsym获取里边的 xc_osdep_info 符号，然后调用符号地址的init函数，并将返回值赋值给 xch->ops ，最后调用
xch->ops->open函数，并将返回值赋值给 xch->ops_handle .
下面分析这段代码：
首先要理解，xc 接口主要用于实现 hypercall , 而系统调用要依赖于具体的domain0操作系统，如 linux / bsd
/ solaris 等多种OS
对应的实现是有所不同的，所以domain0为不同OS的情况下，返回的xc接口其内部实现必定不同，这种情况下，一般的做法是不同OS封装自己的实现，然后在xc_interface_open_common函数里判断OS类型并根据类型返回具体的实现，这是一种运行时做判断的方法，libxc
库没有这么做，它实际上是在编译前就做了判断，其实现如下：
首先，OS相关的代码被抽离出来，作为单独的文件，如xc_linux_osdep.c， xc_solaris.c， xc_netbsd.c ，其他文件是通用的代码，其次， 在 configure 的时候检测具体的OS类型，然后编译对应的osdep代码，不匹配的osdep代码根本不编译
最后，不管哪种OS，最终libxc 库都编译为动态库 ： libxenctrl.so.4.2.0，并置 XENCTRL_OSDEP 环境变量指向得到的动态库。
所以就看到了前面的实现：直接动态加载XENCTRL_OSDEP环境变量指向的动态库，并获取符号 "xc_osdep_info" 符号， 下面以
domain0 是 linux 系统为例，则获取的动态库符号对应的地址里的内容就是：
xc_osdep_info_t xc_osdep_info = { // linux 系统的 xc 接口
.name = "Linux Native OS interface",
.init = &linux_osdep_init,
.fake = 0,
};
则 xc_interface_open_common 函数调用的 init 实际调用的是 linux_osdep_init 函数，该函数实现如下：
libxc/xc_linux_osdep.cstatic struct xc_osdep_ops *linux_osdep_init(xc_interface *xch, enum xc_osdep_type type)
{
switch ( type )
{
case XC_OSDEP_PRIVCMD:
return &linux_privcmd_ops; // hypercall 通过这个结构体实现
case XC_OSDEP_EVTCHN:
return &linux_evtchn_ops;
case XC_OSDEP_GNTTAB:
return &linux_gnttab_ops;
case XC_OSDEP_GNTSHR:
return &linux_gntshr_ops;
default:
return NULL;
}
}
可以看到，init函数主要是根据type类型返回一个控制结构体，如果是hypercall类型（对应XC_OSDEP_PRIVCMD），则返回的是 linux_privcmd_ops
这个结构体的指针，这个结构体的内容如下：
static struct xc_osdep_ops linux_privcmd_ops = {
.open = &linux_privcmd_open, // 这里主要干的是：fd = open("/proc/xen/privcmd", O_RDWR);
.close = &linux_privcmd_close,
.u.privcmd = {
.alloc_hypercall_buffer = &linux_privcmd_alloc_hypercall_buffer,
.free_hypercall_buffer = &linux_privcmd_free_hypercall_buffer,
.hypercall = &linux_privcmd_hypercall, // hypercall 调用
.map_foreign_batch = &linux_privcmd_map_foreign_batch,
.map_foreign_bulk = &linux_privcmd_map_foreign_bulk,
.map_foreign_range = &linux_privcmd_map_foreign_range,
.map_foreign_ranges = &linux_privcmd_map_foreign_ranges,
},
};
其中， .u.privcmd.hypercall 函数就是Xen hypercall 在应用层的实现，linux os dep 的实现如下：
static int linux_privcmd_hypercall(xc_interface *xch, xc_osdep_handle h, privcmd_hypercall_t *hypercall)
{
int fd = (int)h;
return ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, hypercall); // 变成 ioctl 系统调用
}
可以看到，最终是转换为对参数 h 这个Fd 的 ioctl 调用，那么这个h是怎么来的？
回到 xc_interface_open_common函数的实现， 其获取动态库符号后调用的init函数其实是 linux_osdep_init 函数，则保留在 ctx->xch->ops 变量上的是 linux_privcmd_ops 结构体，随即调用 ctx->xch->ops_handle = xch->ops->open(xch) 其实就是调用 linux_privcmd_open 函数，该函数主要代码是 fd = open("/proc/xen/privcmd", O_RDWR); 所以，保留在 ctx->xch->ops_handle上的其实是 /proc/xen/privcmd 打开后的文件描述符。这样，后续进程其他地方需要调用hypercall，则通过 ctx->xch 结构体上的 ops 和 ops_handle , 就可以将各种 hypercall 调用变成对 /proc/xen/privcmd 文件描述符的 ioctl 调用
xen hypercall 的应用层实现,布布扣,bubuko.com