[RFC] VirtFS support on Xen

* [RFC] VirtFS support on Xen
@ 2016-01-21 10:28 Wei Liu
  2016-01-21 10:50 ` David Vrabel
  0 siblings, 1 reply; 13+ messages in thread
From: Wei Liu @ 2016-01-21 10:28 UTC (permalink / raw)
  To: Xen-devel; +Cc: wei.liu2

[RFC] VirtFS support on Xen

# Introduction

QEMU/KVM supports file system passthrough via an interface called
VirtFS [0]. VirtFS is in turn implemented with 9pfs protocol [1] and
VirtIO transport.

Xen used to have its own implementation of file system passthrough
called XenFS, but that has been inactive for a few years. The latest
update was in 2009 [2].

This project aims to add VirtFS support on Xen. This is more
sustainable than inventing our own wheel.

# QEMU

Some preliminary work has been done. The original code made a lot of
assumptions that VirtFS was tied to VirtIO, which wasn't true. Patches
to disentangle VirtFS generic code and VirtIO transport have been
upstreamed. What we now need to do is to implement a Xen transport
inside QEMU.

# Linux kernel

Linux kernel has a better shape than QEMU. The generic code and
transport layers are separated cleanly. We need to add a new transport
for Xen.

# Xen toolstack

New interfaces will be added to exposed relevant configuration options
to users. In essence it is just plumbing the right options to QEMU.

# Security

Xen transport will utilise grant table to limit access from backend to
frontend. Users can use several security modes provided by QEMU.

By and large the security of VirtFS on Xen depends on the quality of
QEMU VirtFS code (this is in line with our expectation of other PV
backends in QEMU) and the particular setup of VirtFS (whether a chroot
fs-proxy is used, which security model is picked etc).

# Device type and wire format

I propose to use "virtfs" as device type. A header file named virtfs.h
shall be committed to xen.git as reference for future implementation.

The design of wire format is limited by two factors: 1) 9pfs protocol
is based on transaction -- client sends out request and expects
response, 2) the arrangement of Linux kernel 9pfs places request
buffer and response buffer on the wire at the same time.

Linux seems to be the only one among several popular UNIX / UNIX-like
systems that has in-kernel 9p protocol implementation (correct me if
I'm wrong), so I couldn't fathom what other OSes such as FreeBSD and
NetBSD would need from this wire format. But it would be safe to bet
that they would like to reuse as much code as possible and follow the
same path as Linux does.

So the conclusion so far is that it would make sense for us to follow
the Linux approach (putting two buffers on wire at the same time) to
minimise our work. Other opinions are welcome.

As for the wire format itself, I've attached a draft from my
code. It's far from complete, but it contains the wire format I
envisage.

# Optimisation

The Xen trasnport can be easily extended to use multiple-page ring
should the need arise. A more sophisticated optimisation is to support
"indirect-descriptor" like interface to boost bandwidth.

Wei.

[0] http://www.linux-kvm.org/page/VirtFS
[1] https://en.wikipedia.org/wiki/9P_(protocol)
[2] https://blog.xenproject.org/2009/03/26/status-of-xenfs/
[3] http://wiki.qemu.org/Documentation/9psetup
[4] http://man.cat-v.org/plan_9/5/intro

DRAFT HEADER

/******************************************************************************
 * virtfs.h
 *
 * Copyright (c) 2016, Wei Liu <wei.liu2@citrix.com>
 */

#ifndef __XEN_PUBLIC_IO_VIRTFS_H__
#define __XEN_PUBLIC_IO_VIRTFS_H__

#include <xen/interface/io/ring.h>
#include <xen/interface/grant_table.h>

struct xen_virtfsif_request {
	grant_ref_t gref;      /* Reference to buffer page */
	uint16_t offset;       /* Offset within buffer page */
	uint16_t flags;        /* XEN_VIRTFSF_* */
	uint16_t id;           /* Echoed in response message. */
};

struct xen_virtfsif_response {
	uint16_t id;
	int16_t  status;	/* Indicate whether backend successfully copy / map */
};

/* TODO: RFC style diagrams go in here */

/* TODO: document xenstore path */
/*
 * /local/domain/$guest/device/virtfs/$x/tag
 * /local/domain/$guest/device/virtfs/$x/ring-ref
 * /local/domain/$guest/device/virtfs/$x/event-channel
 */

/*
 * This is wire format for virtfs requests:
 *   Request 1: xen_virtfsif_request -- XEN_VIRTFSF_* (any flag)
 *   Request 2: xen_virtfsif_request -- if request 1 has XEN_VIRTFSF_MORE
 *   Request 3: xen_virtfsif_request -- if request 2 has XEN_VIRTFSF_MORE
 *   ...
 *   Request N: xen_virtfsif_request -- if request (N-1) has XEN_VIRTFSF_MORE,
 *                                      while itself doesn't contain
 *                                      XEN_VIRTFSF_MORE
 *
 *
 *  | slot 0 | slot 1 | ... | slot m | ... | slot n       |
 *  |       9p request buffer        | 9p response buffer |
 *
 *  Grefs for 9p requests (if any) go in first half of wire format,
 *  grefs for 9p responses (if any) go in second half.
 */

/* If this bit is set, the next slot if part of the request. */
#define _XEN_VIRTFSF_MORE (0)
#define XEN_VIRTFSF_MORE  (1U << _XEN_VIRTFSF_MORE)

/*
 * If this bit is set, this gref is for backend to write data (9p
 * response buffer); otherwise it is for backend to read (9p request
 * buffer).
 */
#define _XEN_VIRTFSF_WRITE (1)
#define XEN_VIRTFSF_WRITE  (1U << _XEN_VIRTFSF_WRITE)

DEFINE_RING_TYPES(xen_virtfsif,
		  struct xen_virtfsif_request,
		  struct xen_virtfsif_response);

#endif /* virtfs.h */

^ permalink raw reply	[flat|nested] 13+ messages in thread