首页 > 代码库 > xen hypercall 的应用层实现

xen hypercall 的应用层实现

一句话描述: 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.c

static 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 调用