[PATCH 1/2] kvm tools: Copy net/9p/9p.h

[PATCH 1/2] kvm tools: Copy net/9p/9p.h

[Sasha Levin]

Header could not be included directly because among some minor
issues, the original header declared the same function twice:
int p9_errstr2errno(char *errstr, int len);
int p9_errstr2errno(char *, int);

A patch has been sent to 9P maintainers, this header should
be removed once the patch is in.

Until then, use a modified copy of the header.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
---
 tools/kvm/include/net/9p/9p.h |  735 +++++++++++++++++++++++++++++++++++++++++
 1 files changed, 735 insertions(+), 0 deletions(-)
 create mode 100644 tools/kvm/include/net/9p/9p.h

diff --git a/tools/kvm/include/net/9p/9p.h b/tools/kvm/include/net/9p/9p.h
new file mode 100644
index 0000000..cc11592
--- /dev/null
+++ b/tools/kvm/include/net/9p/9p.h
@@ -0,0 +1,735 @@
+/*
+ * include/net/9p/9p.h
+ *
+ * 9P protocol definitions.
+ *
+ *  Copyright (C) 2005 by Latchesar Ionkov <lucho@ionkov.net>
+ *  Copyright (C) 2004 by Eric Van Hensbergen <ericvh@gmail.com>
+ *  Copyright (C) 2002 by Ron Minnich <rminnich@lanl.gov>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to:
+ *  Free Software Foundation
+ *  51 Franklin Street, Fifth Floor
+ *  Boston, MA  02111-1301  USA
+ *
+ */
+
+#ifndef NET_9P_H
+#define NET_9P_H
+
+#pragma pack(1)
+
+/**
+ * enum p9_debug_flags - bits for mount time debug parameter
+ * @P9_DEBUG_ERROR: more verbose error messages including original error string
+ * @P9_DEBUG_9P: 9P protocol tracing
+ * @P9_DEBUG_VFS: VFS API tracing
+ * @P9_DEBUG_CONV: protocol conversion tracing
+ * @P9_DEBUG_MUX: trace management of concurrent transactions
+ * @P9_DEBUG_TRANS: transport tracing
+ * @P9_DEBUG_SLABS: memory management tracing
+ * @P9_DEBUG_FCALL: verbose dump of protocol messages
+ * @P9_DEBUG_FID: fid allocation/deallocation tracking
+ * @P9_DEBUG_PKT: packet marshalling/unmarshalling
+ * @P9_DEBUG_FSC: FS-cache tracing
+ *
+ * These flags are passed at mount time to turn on various levels of
+ * verbosity and tracing which will be output to the system logs.
+ */
+
+enum p9_debug_flags {
+	P9_DEBUG_ERROR =	(1<<0),
+	P9_DEBUG_9P =		(1<<2),
+	P9_DEBUG_VFS =		(1<<3),
+	P9_DEBUG_CONV =		(1<<4),
+	P9_DEBUG_MUX =		(1<<5),
+	P9_DEBUG_TRANS =	(1<<6),
+	P9_DEBUG_SLABS =	(1<<7),
+	P9_DEBUG_FCALL =	(1<<8),
+	P9_DEBUG_FID =		(1<<9),
+	P9_DEBUG_PKT =		(1<<10),
+	P9_DEBUG_FSC =		(1<<11),
+};
+
+#ifdef CONFIG_NET_9P_DEBUG
+extern unsigned int p9_debug_level;
+
+#define P9_DPRINTK(level, format, arg...) \
+do {  \
+	if ((p9_debug_level & level) == level) {\
+		if (level == P9_DEBUG_9P) \
+			printk(KERN_NOTICE "(%8.8d) " \
+			format , task_pid_nr(current) , ## arg); \
+		else \
+			printk(KERN_NOTICE "-- %s (%d): " \
+			format , __func__, task_pid_nr(current) , ## arg); \
+	} \
+} while (0)
+
+#else
+#define P9_DPRINTK(level, format, arg...)  do { } while (0)
+#endif
+
+#define P9_EPRINTK(level, format, arg...) \
+do { \
+	printk(level "9p: %s (%d): " \
+		format , __func__, task_pid_nr(current), ## arg); \
+} while (0)
+
+/**
+ * enum p9_msg_t - 9P message types
+ * @P9_TLERROR: not used
+ * @P9_RLERROR: response for any failed request for 9P2000.L
+ * @P9_TSTATFS: file system status request
+ * @P9_RSTATFS: file system status response
+ * @P9_TSYMLINK: make symlink request
+ * @P9_RSYMLINK: make symlink response
+ * @P9_TMKNOD: create a special file object request
+ * @P9_RMKNOD: create a special file object response
+ * @P9_TLCREATE: prepare a handle for I/O on an new file for 9P2000.L
+ * @P9_RLCREATE: response with file access information for 9P2000.L
+ * @P9_TRENAME: rename request
+ * @P9_RRENAME: rename response
+ * @P9_TMKDIR: create a directory request
+ * @P9_RMKDIR: create a directory response
+ * @P9_TVERSION: version handshake request
+ * @P9_RVERSION: version handshake response
+ * @P9_TAUTH: request to establish authentication channel
+ * @P9_RAUTH: response with authentication information
+ * @P9_TATTACH: establish user access to file service
+ * @P9_RATTACH: response with top level handle to file hierarchy
+ * @P9_TERROR: not used
+ * @P9_RERROR: response for any failed request
+ * @P9_TFLUSH: request to abort a previous request
+ * @P9_RFLUSH: response when previous request has been cancelled
+ * @P9_TWALK: descend a directory hierarchy
+ * @P9_RWALK: response with new handle for position within hierarchy
+ * @P9_TOPEN: prepare a handle for I/O on an existing file
+ * @P9_ROPEN: response with file access information
+ * @P9_TCREATE: prepare a handle for I/O on a new file
+ * @P9_RCREATE: response with file access information
+ * @P9_TREAD: request to transfer data from a file or directory
+ * @P9_RREAD: response with data requested
+ * @P9_TWRITE: reuqest to transfer data to a file
+ * @P9_RWRITE: response with out much data was transferred to file
+ * @P9_TCLUNK: forget about a handle to an entity within the file system
+ * @P9_RCLUNK: response when server has forgotten about the handle
+ * @P9_TREMOVE: request to remove an entity from the hierarchy
+ * @P9_RREMOVE: response when server has removed the entity
+ * @P9_TSTAT: request file entity attributes
+ * @P9_RSTAT: response with file entity attributes
+ * @P9_TWSTAT: request to update file entity attributes
+ * @P9_RWSTAT: response when file entity attributes are updated
+ *
+ * There are 14 basic operations in 9P2000, paired as
+ * requests and responses.  The one special case is ERROR
+ * as there is no @P9_TERROR request for clients to transmit to
+ * the server, but the server may respond to any other request
+ * with an @P9_RERROR.
+ *
+ * See Also: http://plan9.bell-labs.com/sys/man/5/INDEX.html
+ */
+
+enum p9_msg_t {
+	P9_TLERROR = 6,
+	P9_RLERROR,
+	P9_TSTATFS = 8,
+	P9_RSTATFS,
+	P9_TLOPEN = 12,
+	P9_RLOPEN,
+	P9_TLCREATE = 14,
+	P9_RLCREATE,
+	P9_TSYMLINK = 16,
+	P9_RSYMLINK,
+	P9_TMKNOD = 18,
+	P9_RMKNOD,
+	P9_TRENAME = 20,
+	P9_RRENAME,
+	P9_TREADLINK = 22,
+	P9_RREADLINK,
+	P9_TGETATTR = 24,
+	P9_RGETATTR,
+	P9_TSETATTR = 26,
+	P9_RSETATTR,
+	P9_TXATTRWALK = 30,
+	P9_RXATTRWALK,
+	P9_TXATTRCREATE = 32,
+	P9_RXATTRCREATE,
+	P9_TREADDIR = 40,
+	P9_RREADDIR,
+	P9_TFSYNC = 50,
+	P9_RFSYNC,
+	P9_TLOCK = 52,
+	P9_RLOCK,
+	P9_TGETLOCK = 54,
+	P9_RGETLOCK,
+	P9_TLINK = 70,
+	P9_RLINK,
+	P9_TMKDIR = 72,
+	P9_RMKDIR,
+	P9_TVERSION = 100,
+	P9_RVERSION,
+	P9_TAUTH = 102,
+	P9_RAUTH,
+	P9_TATTACH = 104,
+	P9_RATTACH,
+	P9_TERROR = 106,
+	P9_RERROR,
+	P9_TFLUSH = 108,
+	P9_RFLUSH,
+	P9_TWALK = 110,
+	P9_RWALK,
+	P9_TOPEN = 112,
+	P9_ROPEN,
+	P9_TCREATE = 114,
+	P9_RCREATE,
+	P9_TREAD = 116,
+	P9_RREAD,
+	P9_TWRITE = 118,
+	P9_RWRITE,
+	P9_TCLUNK = 120,
+	P9_RCLUNK,
+	P9_TREMOVE = 122,
+	P9_RREMOVE,
+	P9_TSTAT = 124,
+	P9_RSTAT,
+	P9_TWSTAT = 126,
+	P9_RWSTAT,
+};
+
+/**
+ * enum p9_open_mode_t - 9P open modes
+ * @P9_OREAD: open file for reading only
+ * @P9_OWRITE: open file for writing only
+ * @P9_ORDWR: open file for reading or writing
+ * @P9_OEXEC: open file for execution
+ * @P9_OTRUNC: truncate file to zero-length before opening it
+ * @P9_OREXEC: close the file when an exec(2) system call is made
+ * @P9_ORCLOSE: remove the file when the file is closed
+ * @P9_OAPPEND: open the file and seek to the end
+ * @P9_OEXCL: only create a file, do not open it
+ *
+ * 9P open modes differ slightly from Posix standard modes.
+ * In particular, there are extra modes which specify different
+ * semantic behaviors than may be available on standard Posix
+ * systems.  For example, @P9_OREXEC and @P9_ORCLOSE are modes that
+ * most likely will not be issued from the Linux VFS client, but may
+ * be supported by servers.
+ *
+ * See Also: http://plan9.bell-labs.com/magic/man2html/2/open
+ */
+
+enum p9_open_mode_t {
+	P9_OREAD = 0x00,
+	P9_OWRITE = 0x01,
+	P9_ORDWR = 0x02,
+	P9_OEXEC = 0x03,
+	P9_OTRUNC = 0x10,
+	P9_OREXEC = 0x20,
+	P9_ORCLOSE = 0x40,
+	P9_OAPPEND = 0x80,
+	P9_OEXCL = 0x1000,
+};
+
+/**
+ * enum p9_perm_t - 9P permissions
+ * @P9_DMDIR: mode bite for directories
+ * @P9_DMAPPEND: mode bit for is append-only
+ * @P9_DMEXCL: mode bit for excluse use (only one open handle allowed)
+ * @P9_DMMOUNT: mode bite for mount points
+ * @P9_DMAUTH: mode bit for authentication file
+ * @P9_DMTMP: mode bit for non-backed-up files
+ * @P9_DMSYMLINK: mode bit for symbolic links (9P2000.u)
+ * @P9_DMLINK: mode bit for hard-link (9P2000.u)
+ * @P9_DMDEVICE: mode bit for device files (9P2000.u)
+ * @P9_DMNAMEDPIPE: mode bit for named pipe (9P2000.u)
+ * @P9_DMSOCKET: mode bit for socket (9P2000.u)
+ * @P9_DMSETUID: mode bit for setuid (9P2000.u)
+ * @P9_DMSETGID: mode bit for setgid (9P2000.u)
+ * @P9_DMSETVTX: mode bit for sticky bit (9P2000.u)
+ *
+ * 9P permissions differ slightly from Posix standard modes.
+ *
+ * See Also: http://plan9.bell-labs.com/magic/man2html/2/stat
+ */
+enum p9_perm_t {
+	P9_DMDIR = 0x80000000,
+	P9_DMAPPEND = 0x40000000,
+	P9_DMEXCL = 0x20000000,
+	P9_DMMOUNT = 0x10000000,
+	P9_DMAUTH = 0x08000000,
+	P9_DMTMP = 0x04000000,
+/* 9P2000.u extensions */
+	P9_DMSYMLINK = 0x02000000,
+	P9_DMLINK = 0x01000000,
+	P9_DMDEVICE = 0x00800000,
+	P9_DMNAMEDPIPE = 0x00200000,
+	P9_DMSOCKET = 0x00100000,
+	P9_DMSETUID = 0x00080000,
+	P9_DMSETGID = 0x00040000,
+	P9_DMSETVTX = 0x00010000,
+};
+
+/**
+ * enum p9_qid_t - QID types
+ * @P9_QTDIR: directory
+ * @P9_QTAPPEND: append-only
+ * @P9_QTEXCL: excluse use (only one open handle allowed)
+ * @P9_QTMOUNT: mount points
+ * @P9_QTAUTH: authentication file
+ * @P9_QTTMP: non-backed-up files
+ * @P9_QTSYMLINK: symbolic links (9P2000.u)
+ * @P9_QTLINK: hard-link (9P2000.u)
+ * @P9_QTFILE: normal files
+ *
+ * QID types are a subset of permissions - they are primarily
+ * used to differentiate semantics for a file system entity via
+ * a jump-table.  Their value is also the most significant 16 bits
+ * of the permission_t
+ *
+ * See Also: http://plan9.bell-labs.com/magic/man2html/2/stat
+ */
+enum p9_qid_t {
+	P9_QTDIR = 0x80,
+	P9_QTAPPEND = 0x40,
+	P9_QTEXCL = 0x20,
+	P9_QTMOUNT = 0x10,
+	P9_QTAUTH = 0x08,
+	P9_QTTMP = 0x04,
+	P9_QTSYMLINK = 0x02,
+	P9_QTLINK = 0x01,
+	P9_QTFILE = 0x00,
+};
+
+/* 9P Magic Numbers */
+#define P9_NOTAG	(u16)(~0)
+#define P9_NOFID	(u32)(~0)
+#define P9_MAXWELEM	16
+
+/* ample room for Twrite/Rread header */
+#define P9_IOHDRSZ	24
+
+/* Room for readdir header */
+#define P9_READDIRHDRSZ	24
+
+/**
+ * struct p9_str - length prefixed string type
+ * @len: length of the string
+ * @str: the string
+ *
+ * The protocol uses length prefixed strings for all
+ * string data, so we replicate that for our internal
+ * string members.
+ */
+
+struct p9_str {
+	u16 len;
+	char *str;
+};
+
+/**
+ * struct p9_qid - file system entity information
+ * @type: 8-bit type &p9_qid_t
+ * @version: 16-bit monotonically incrementing version number
+ * @path: 64-bit per-server-unique ID for a file system element
+ *
+ * qids are identifiers used by 9P servers to track file system
+ * entities.  The type is used to differentiate semantics for operations
+ * on the entity (ie. read means something different on a directory than
+ * on a file).  The path provides a server unique index for an entity
+ * (roughly analogous to an inode number), while the version is updated
+ * every time a file is modified and can be used to maintain cache
+ * coherency between clients and serves.
+ * Servers will often differentiate purely synthetic entities by setting
+ * their version to 0, signaling that they should never be cached and
+ * should be accessed synchronously.
+ *
+ * See Also://plan9.bell-labs.com/magic/man2html/2/stat
+ */
+
+struct p9_qid {
+	u8 type;
+	u32 version;
+	u64 path;
+};
+
+/**
+ * struct p9_stat - file system metadata information
+ * @size: length prefix for this stat structure instance
+ * @type: the type of the server (equivalent to a major number)
+ * @dev: the sub-type of the server (equivalent to a minor number)
+ * @qid: unique id from the server of type &p9_qid
+ * @mode: Plan 9 format permissions of type &p9_perm_t
+ * @atime: Last access/read time
+ * @mtime: Last modify/write time
+ * @length: file length
+ * @name: last element of path (aka filename) in type &p9_str
+ * @uid: owner name in type &p9_str
+ * @gid: group owner in type &p9_str
+ * @muid: last modifier in type &p9_str
+ * @extension: area used to encode extended UNIX support in type &p9_str
+ * @n_uid: numeric user id of owner (part of 9p2000.u extension)
+ * @n_gid: numeric group id (part of 9p2000.u extension)
+ * @n_muid: numeric user id of laster modifier (part of 9p2000.u extension)
+ *
+ * See Also: http://plan9.bell-labs.com/magic/man2html/2/stat
+ */
+
+struct p9_wstat {
+	u16 size;
+	u16 type;
+	u32 dev;
+	struct p9_qid qid;
+	u32 mode;
+	u32 atime;
+	u32 mtime;
+	u64 length;
+	char *name;
+	char *uid;
+	char *gid;
+	char *muid;
+	char *extension;	/* 9p2000.u extensions */
+	u32 n_uid;		/* 9p2000.u extensions */
+	u32 n_gid;		/* 9p2000.u extensions */
+	u32 n_muid;		/* 9p2000.u extensions */
+};
+
+struct p9_stat_dotl {
+	u64 st_result_mask;
+	struct p9_qid qid;
+	u32 st_mode;
+	u32 st_uid;
+	u32 st_gid;
+	u64 st_nlink;
+	u64 st_rdev;
+	u64 st_size;
+	u64 st_blksize;
+	u64 st_blocks;
+	u64 st_atime_sec;
+	u64 st_atime_nsec;
+	u64 st_mtime_sec;
+	u64 st_mtime_nsec;
+	u64 st_ctime_sec;
+	u64 st_ctime_nsec;
+	u64 st_btime_sec;
+	u64 st_btime_nsec;
+	u64 st_gen;
+	u64 st_data_version;
+};
+
+#define P9_STATS_MODE		0x00000001ULL
+#define P9_STATS_NLINK		0x00000002ULL
+#define P9_STATS_UID		0x00000004ULL
+#define P9_STATS_GID		0x00000008ULL
+#define P9_STATS_RDEV		0x00000010ULL
+#define P9_STATS_ATIME		0x00000020ULL
+#define P9_STATS_MTIME		0x00000040ULL
+#define P9_STATS_CTIME		0x00000080ULL
+#define P9_STATS_INO		0x00000100ULL
+#define P9_STATS_SIZE		0x00000200ULL
+#define P9_STATS_BLOCKS		0x00000400ULL
+
+#define P9_STATS_BTIME		0x00000800ULL
+#define P9_STATS_GEN		0x00001000ULL
+#define P9_STATS_DATA_VERSION	0x00002000ULL
+
+#define P9_STATS_BASIC		0x000007ffULL /* Mask for fields up to BLOCKS */
+#define P9_STATS_ALL		0x00003fffULL /* Mask for All fields above */
+
+/**
+ * struct p9_iattr_dotl - P9 inode attribute for setattr
+ * @valid: bitfield specifying which fields are valid
+ *         same as in struct iattr
+ * @mode: File permission bits
+ * @uid: user id of owner
+ * @gid: group id
+ * @size: File size
+ * @atime_sec: Last access time, seconds
+ * @atime_nsec: Last access time, nanoseconds
+ * @mtime_sec: Last modification time, seconds
+ * @mtime_nsec: Last modification time, nanoseconds
+ */
+
+struct p9_iattr_dotl {
+	u32 valid;
+	u32 mode;
+	u32 uid;
+	u32 gid;
+	u64 size;
+	u64 atime_sec;
+	u64 atime_nsec;
+	u64 mtime_sec;
+	u64 mtime_nsec;
+};
+
+#define P9_LOCK_SUCCESS 0
+#define P9_LOCK_BLOCKED 1
+#define P9_LOCK_ERROR 2
+#define P9_LOCK_GRACE 3
+
+#define P9_LOCK_FLAGS_BLOCK 1
+#define P9_LOCK_FLAGS_RECLAIM 2
+
+/* struct p9_flock: POSIX lock structure
+ * @type - type of lock
+ * @flags - lock flags
+ * @start - starting offset of the lock
+ * @length - number of bytes
+ * @proc_id - process id which wants to take lock
+ * @client_id - client id
+ */
+
+struct p9_flock {
+	u8 type;
+	u32 flags;
+	u64 start;
+	u64 length;
+	u32 proc_id;
+	char *client_id;
+};
+
+/* struct p9_getlock: getlock structure
+ * @type - type of lock
+ * @start - starting offset of the lock
+ * @length - number of bytes
+ * @proc_id - process id which wants to take lock
+ * @client_id - client id
+ */
+
+struct p9_getlock {
+	u8 type;
+	u64 start;
+	u64 length;
+	u32 proc_id;
+	char *client_id;
+};
+
+/* Structures for Protocol Operations */
+struct p9_tstatfs {
+	u32 fid;
+};
+
+struct p9_rstatfs {
+	u32 type;
+	u32 bsize;
+	u64 blocks;
+	u64 bfree;
+	u64 bavail;
+	u64 files;
+	u64 ffree;
+	u64 fsid;
+	u32 namelen;
+};
+
+struct p9_trename {
+	u32 fid;
+	u32 newdirfid;
+	struct p9_str name;
+};
+
+struct p9_rrename {
+};
+
+struct p9_tversion {
+	u32 msize;
+	struct p9_str version;
+};
+
+struct p9_rversion {
+	u32 msize;
+	struct p9_str version;
+};
+
+struct p9_tauth {
+	u32 afid;
+	struct p9_str uname;
+	struct p9_str aname;
+	u32 n_uname;		/* 9P2000.u extensions */
+};
+
+struct p9_rauth {
+	struct p9_qid qid;
+};
+
+struct p9_rerror {
+	struct p9_str error;
+	u32 _errno;		/* 9p2000.u extension */
+};
+
+struct p9_tflush {
+	u16 oldtag;
+};
+
+struct p9_rflush {
+};
+
+struct p9_tattach {
+	u32 fid;
+	u32 afid;
+	struct p9_str uname;
+	struct p9_str aname;
+	u32 n_uname;		/* 9P2000.u extensions */
+};
+
+struct p9_rattach {
+	struct p9_qid qid;
+};
+
+struct p9_twalk {
+	u32 fid;
+	u32 newfid;
+	u16 nwname;
+	struct p9_str wnames[16];
+};
+
+struct p9_rwalk {
+	u16 nwqid;
+	struct p9_qid wqids[16];
+};
+
+struct p9_topen {
+	u32 fid;
+	u8 mode;
+};
+
+struct p9_ropen {
+	struct p9_qid qid;
+	u32 iounit;
+};
+
+struct p9_tcreate {
+	u32 fid;
+	struct p9_str name;
+	u32 perm;
+	u8 mode;
+	struct p9_str extension;
+};
+
+struct p9_rcreate {
+	struct p9_qid qid;
+	u32 iounit;
+};
+
+struct p9_tread {
+	u32 fid;
+	u64 offset;
+	u32 count;
+};
+
+struct p9_rread {
+	u32 count;
+	u8 *data;
+};
+
+struct p9_twrite {
+	u32 fid;
+	u64 offset;
+	u32 count;
+	u8 *data;
+};
+
+struct p9_rwrite {
+	u32 count;
+};
+
+struct p9_treaddir {
+	u32 fid;
+	u64 offset;
+	u32 count;
+};
+
+struct p9_rreaddir {
+	u32 count;
+	u8 *data;
+};
+
+
+struct p9_tclunk {
+	u32 fid;
+};
+
+struct p9_rclunk {
+};
+
+struct p9_tremove {
+	u32 fid;
+};
+
+struct p9_rremove {
+};
+
+struct p9_tstat {
+	u32 fid;
+};
+
+struct p9_rstat {
+	struct p9_wstat stat;
+};
+
+struct p9_twstat {
+	u32 fid;
+	struct p9_wstat stat;
+};
+
+struct p9_rwstat {
+};
+
+/**
+ * struct p9_fcall - primary packet structure
+ * @size: prefixed length of the structure
+ * @id: protocol operating identifier of type &p9_msg_t
+ * @tag: transaction id of the request
+ * @offset: used by marshalling routines to track currentposition in buffer
+ * @capacity: used by marshalling routines to track total malloc'd capacity
+ * @pubuf: Payload user buffer given by the caller
+ * @pubuf: Payload kernel buffer given by the caller
+ * @pbuf_size: pubuf/pkbuf(only one will be !NULL) size to be read/write.
+ * @private: For transport layer's use.
+ * @sdata: payload
+ *
+ * &p9_fcall represents the structure for all 9P RPC
+ * transactions.  Requests are packaged into fcalls, and reponses
+ * must be extracted from them.
+ *
+ * See Also: http://plan9.bell-labs.com/magic/man2html/2/fcall
+ */
+
+struct p9_fcall {
+	u32 size;
+	u8 id;
+	u16 tag;
+
+	size_t offset;
+	size_t capacity;
+	char __user *pubuf;
+	char *pkbuf;
+	size_t pbuf_size;
+	void *private;
+
+	u8 *sdata;
+};
+
+struct p9_idpool;
+
+int p9_errstr2errno(char *errstr, int len);
+
+struct p9_idpool *p9_idpool_create(void);
+void p9_idpool_destroy(struct p9_idpool *);
+int p9_idpool_get(struct p9_idpool *p);
+void p9_idpool_put(int id, struct p9_idpool *p);
+int p9_idpool_check(int id, struct p9_idpool *p);
+
+int p9_error_init(void);
+int p9_trans_fd_init(void);
+void p9_trans_fd_exit(void);
+#endif /* NET_9P_H */
-- 
1.7.5.rc3

[PATCH 2/2] kvm tools: Add virtio-9p

[Sasha Levin]

Overview:
9p allows for simple RPC based resource sharing over
different transports (in our case, virtio).

This is the implementation of (most of) the original
9p2000 protocol, without the .u or the .l extensions.

How to use:
1. Make sure kernel is compiled with:
    CONFIG_NET_9P=y
    CONFIG_NET_9P_VIRTIO=y
    CONFIG_NET_9P_DEBUG=y (At least until code is stable)
    CONFIG_9P_FS=y

2. Start KVM with '--virtio-9p <dirname>'. What happens now is that
a virtio transport with the name 'kvm_9p' is created. The server side
of the transport maps dirname to the root of the file system.

3. Within the guest, mount the fs:
mount -t 9p -otrans=virtio kvm_9p <local_dir> -oversion=9p2000
This will mount the 9p server to local_dir.

Still todo (but can live without):
 - Multiple virtio-9p devices.
 - Ugly hack in virtio_p9_stat() (See desc in code).
 - Update atime/mtime in p9_wstat, not really needed.
 - Pass usernames in p9_stat, not really needed and not really sure how
p9 expects to handle them.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
---
 tools/kvm/Makefile                     |    1 +
 tools/kvm/include/kvm/ioport.h         |    2 +
 tools/kvm/include/kvm/virtio-9p.h      |    8 +
 tools/kvm/include/kvm/virtio-pci-dev.h |    1 +
 tools/kvm/kvm-run.c                    |   13 +
 tools/kvm/virtio/9p.c                  |  660 ++++++++++++++++++++++++++++++++
 6 files changed, 685 insertions(+), 0 deletions(-)
 create mode 100644 tools/kvm/include/kvm/virtio-9p.h
 create mode 100644 tools/kvm/virtio/9p.c

diff --git a/tools/kvm/Makefile b/tools/kvm/Makefile
index 45897d5..805a0da 100644
--- a/tools/kvm/Makefile
+++ b/tools/kvm/Makefile
@@ -43,6 +43,7 @@ OBJS    += threadpool.o
 OBJS    += irq.o
 OBJS    += ../../lib/rbtree.o
 OBJS    += util/rbtree-interval.o
+OBJS    += virtio/9p.o
 
 DEPS	:= $(patsubst %.o,%.d,$(OBJS))
 
diff --git a/tools/kvm/include/kvm/ioport.h b/tools/kvm/include/kvm/ioport.h
index b9bbc3d..218530c 100644
--- a/tools/kvm/include/kvm/ioport.h
+++ b/tools/kvm/include/kvm/ioport.h
@@ -7,6 +7,8 @@
 
 /* some ports we reserve for own use */
 #define IOPORT_DBG			0xe0
+#define IOPORT_VIRTIO_P9		0xb200	/* Virtio 9P device */
+#define IOPORT_VIRTIO_P9_SIZE		256
 #define IOPORT_VIRTIO_BLK		0xc200	/* Virtio block device */
 #define IOPORT_VIRTIO_BLK_SIZE		0x200
 #define IOPORT_VIRTIO_CONSOLE		0xd200	/* Virtio console device */
diff --git a/tools/kvm/include/kvm/virtio-9p.h b/tools/kvm/include/kvm/virtio-9p.h
new file mode 100644
index 0000000..9052830
--- /dev/null
+++ b/tools/kvm/include/kvm/virtio-9p.h
@@ -0,0 +1,8 @@
+#ifndef KVM__VIRTIO_9P_H
+#define KVM__VIRTIO_9P_H
+
+struct kvm;
+
+void virtio_9p__init(struct kvm *kvm, const char *root);
+
+#endif
diff --git a/tools/kvm/include/kvm/virtio-pci-dev.h b/tools/kvm/include/kvm/virtio-pci-dev.h
index fa8328d..1b7862e 100644
--- a/tools/kvm/include/kvm/virtio-pci-dev.h
+++ b/tools/kvm/include/kvm/virtio-pci-dev.h
@@ -12,6 +12,7 @@
 #define PCI_DEVICE_ID_VIRTIO_BLK		0x1001
 #define PCI_DEVICE_ID_VIRTIO_CONSOLE		0x1003
 #define PCI_DEVICE_ID_VIRTIO_RNG		0x1004
+#define PCI_DEVICE_ID_VIRTIO_P9			0x1009
 
 #define PCI_VENDOR_ID_REDHAT_QUMRANET		0x1af4
 #define PCI_SUBSYSTEM_VENDOR_ID_REDHAT_QUMRANET	0x1af4
diff --git a/tools/kvm/kvm-run.c b/tools/kvm/kvm-run.c
index ba8e5ce..dc16a70 100644
--- a/tools/kvm/kvm-run.c
+++ b/tools/kvm/kvm-run.c
@@ -27,6 +27,7 @@
 #include <kvm/threadpool.h>
 #include <kvm/barrier.h>
 #include <kvm/symbol.h>
+#include <kvm/virtio-9p.h>
 
 /* header files for gitish interface  */
 #include <kvm/kvm-run.h>
@@ -62,6 +63,7 @@ static const char *network;
 static const char *host_ip_addr;
 static const char *guest_mac;
 static const char *script;
+static const char *virtio_9p_dir;
 static bool single_step;
 static bool readonly_image[MAX_DISK_IMAGES];
 static bool virtio_rng;
@@ -107,6 +109,8 @@ static const struct option options[] = {
 	OPT_BOOLEAN('\0', "rng", &virtio_rng,
 			"Enable virtio Random Number Generator"),
 	OPT_STRING('\0', "kvm-dev", &kvm_dev, "kvm-dev", "KVM device file"),
+	OPT_STRING('\0', "virtio-9p", &virtio_9p_dir, "root dir",
+			"Enable 9p over virtio"),
 
 	OPT_GROUP("Kernel options:"),
 	OPT_STRING('k', "kernel", &kernel_filename, "kernel",
@@ -463,6 +467,15 @@ int kvm_cmd_run(int argc, const char **argv, const char *prefix)
 	if (!script)
 		script = DEFAULT_SCRIPT;
 
+	if (virtio_9p_dir) {
+		char tmp[PATH_MAX];
+
+		if (realpath(virtio_9p_dir, tmp))
+			virtio_9p__init(kvm, tmp);
+		else
+			die("Failed resolving 9p path");
+	}
+
 	symbol__init(vmlinux_filename);
 
 	term_init();
diff --git a/tools/kvm/virtio/9p.c b/tools/kvm/virtio/9p.c
new file mode 100644
index 0000000..376c855
--- /dev/null
+++ b/tools/kvm/virtio/9p.c
@@ -0,0 +1,660 @@
+#include "kvm/virtio-9p.h"
+#include "kvm/virtio-pci-dev.h"
+#include "kvm/virtio.h"
+#include "kvm/ioport.h"
+#include "kvm/mutex.h"
+#include "kvm/util.h"
+#include "kvm/kvm.h"
+#include "kvm/pci.h"
+#include "kvm/threadpool.h"
+#include "kvm/irq.h"
+
+#include <linux/virtio_ring.h>
+#include <linux/virtio_9p.h>
+#include <net/9p/9p.h>
+
+#include <fcntl.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <pthread.h>
+#include <dirent.h>
+
+#define NUM_VIRT_QUEUES		1
+#define VIRTIO_P9_QUEUE_SIZE	128
+#define	VIRTIO_P9_TAG		"kvm_9p"
+#define VIRTIO_P9_HDR_LEN	(sizeof(u32)+sizeof(u8)+sizeof(u16))
+#define VIRTIO_P9_MAX_FID	32
+#define VIRTIO_P9_VERSION	"9P2000"
+
+struct p9_msg {
+	u32			size;
+	u8			cmd;
+	u16			tag;
+	u8			msg[0];
+} __attribute__((aligned (8)));
+
+struct p9_fid {
+	u32 fid;
+	u8 is_dir;
+	char path[PATH_MAX];
+	DIR *dir;
+	int fd;
+};
+
+static struct pci_device_header virtio_p9_pci_device = {
+	.vendor_id		= PCI_VENDOR_ID_REDHAT_QUMRANET,
+	.device_id		= PCI_DEVICE_ID_VIRTIO_P9,
+	.header_type		= PCI_HEADER_TYPE_NORMAL,
+	.revision_id		= 0,
+	.class			= 0x010000,
+	.subsys_vendor_id	= PCI_SUBSYSTEM_VENDOR_ID_REDHAT_QUMRANET,
+	.subsys_id		= VIRTIO_ID_9P,
+	.bar[0]			= IOPORT_VIRTIO_P9 | PCI_BASE_ADDRESS_SPACE_IO,
+};
+
+struct p9_dev {
+	u8			status;
+	u8			isr;
+	u16			config_vector;
+	u32			features;
+	struct virtio_9p_config	*config;
+
+	/* virtio queue */
+	u16			queue_selector;
+	struct virt_queue	vqs[NUM_VIRT_QUEUES];
+	void			*jobs[NUM_VIRT_QUEUES];
+
+	struct p9_fid		fids[VIRTIO_P9_MAX_FID];
+	char			root_dir[PATH_MAX];
+};
+
+static struct p9_dev p9dev;
+
+/* Warning: Immediately use value returned from this function */
+static const char *rel_to_abs_root(const char *path)
+{
+	static char real_path[PATH_MAX];
+
+	sprintf(real_path, "%s/%s", p9dev.root_dir, path);
+
+	return real_path;
+}
+
+static bool virtio_p9_dev_in(void *data, unsigned long offset, int size, u32 count)
+{
+	u8 *config_space = (u8 *) p9dev.config;
+
+	if (size != 1 || count != 1)
+		return false;
+
+	ioport__write8(data, config_space[offset - VIRTIO_MSI_CONFIG_VECTOR]);
+
+	return true;
+}
+
+static bool virtio_p9_pci_io_in(struct kvm *kvm, u16 port, void *data, int size, u32 count)
+{
+	unsigned long offset;
+	bool ret = true;
+
+	offset = port - IOPORT_VIRTIO_P9;
+
+	switch (offset) {
+	case VIRTIO_PCI_HOST_FEATURES:
+		ioport__write32(data, p9dev.features);
+		ret = true;
+		break;
+	case VIRTIO_PCI_GUEST_FEATURES:
+	case VIRTIO_PCI_QUEUE_SEL:
+	case VIRTIO_PCI_QUEUE_NOTIFY:
+		ret = false;
+		break;
+	case VIRTIO_PCI_QUEUE_PFN:
+		ioport__write32(data, p9dev.vqs[p9dev.queue_selector].pfn);
+		break;
+	case VIRTIO_PCI_QUEUE_NUM:
+		ioport__write16(data, VIRTIO_P9_QUEUE_SIZE);
+		break;
+	case VIRTIO_PCI_STATUS:
+		ioport__write8(data, p9dev.status);
+		break;
+	case VIRTIO_PCI_ISR:
+		ioport__write8(data, p9dev.isr);
+		kvm__irq_line(kvm, virtio_p9_pci_device.irq_line, VIRTIO_IRQ_LOW);
+		p9dev.isr = VIRTIO_IRQ_LOW;
+		break;
+	default:
+		ret = virtio_p9_dev_in(data, offset, size, count);
+		break;
+	};
+
+	return ret;
+}
+
+static int omode2uflags(u8 mode)
+{
+	int ret = 0;
+
+	/* Basic open modes are same as uflags */
+	ret = mode & 3;
+
+	/* Everything else is different */
+	if (mode & P9_OTRUNC)
+		ret |= O_TRUNC;
+
+	if (mode & P9_OAPPEND)
+		ret |= O_APPEND;
+
+	if (mode & P9_OEXCL)
+		ret |= O_EXCL;
+
+	return ret;
+}
+
+static void st2qid(struct stat *st, struct p9_qid *qid)
+{
+	*qid = (struct p9_qid) {
+		.path	= st->st_ino,
+		.version	= st->st_mtime,
+	};
+
+	if (S_ISDIR(st->st_mode))
+		qid->type	|= P9_QTDIR;
+}
+
+static void close_fid(u32 fid)
+{
+	if (p9dev.fids[fid].fd > 0) {
+		close(p9dev.fids[fid].fd);
+		p9dev.fids[fid].fd = -1;
+	}
+	if (p9dev.fids[fid].dir) {
+		closedir(p9dev.fids[fid].dir);
+		p9dev.fids[fid].dir = NULL;
+	}
+}
+
+static void set_p9msg_hdr(struct p9_msg *msg, u32 size, u8 cmd, u16 tag)
+{
+	*msg = (struct p9_msg) {
+		.size	= size,
+		.tag	= tag,
+		.cmd	= cmd,
+	};
+}
+
+static bool virtio_p9_version(struct p9_msg *msg, u32 len, struct iovec *iov, u32 *outlen)
+{
+	struct p9_msg *outmsg = iov[0].iov_base;
+	struct p9_rversion *rversion = (struct p9_rversion *)outmsg->msg;
+
+	rversion->msize		= 4096;
+	rversion->version.len	= strlen(VIRTIO_P9_VERSION);
+	memcpy(&rversion->version.str, VIRTIO_P9_VERSION, rversion->version.len);
+
+	*outlen = VIRTIO_P9_HDR_LEN + rversion->version.len + sizeof(u16) + sizeof(u32);
+	set_p9msg_hdr(outmsg, *outlen, P9_RVERSION, msg->tag);
+
+	return true;
+}
+
+static bool virtio_p9_clunk(struct p9_msg *msg, u32 len, struct iovec *iov, u32 *outlen)
+{
+	struct p9_msg *outmsg = iov[0].iov_base;
+	struct p9_tclunk *tclunk = (struct p9_tclunk *)msg->msg;
+
+	close_fid(tclunk->fid);
+
+	*outlen = VIRTIO_P9_HDR_LEN;
+	set_p9msg_hdr(outmsg, *outlen, P9_RCLUNK, msg->tag);
+
+	return true;
+}
+
+static bool virtio_p9_open(struct p9_msg *msg, u32 len, struct iovec *iov, u32 *outlen)
+{
+	struct p9_msg *outmsg	= iov[0].iov_base;
+	struct p9_topen *topen	= (struct p9_topen *)msg->msg;
+	struct p9_ropen *ropen	= (struct p9_ropen *)outmsg->msg;
+	struct p9_fid *new_fid	= &p9dev.fids[topen->fid];
+	struct stat st;
+
+	if (stat(rel_to_abs_root(new_fid->path), &st) < 0)
+		return false;
+
+	st2qid(&st, &ropen->qid);
+	ropen->iounit = 0;
+
+	if (new_fid->is_dir)
+		new_fid->dir	= opendir(rel_to_abs_root(new_fid->path));
+	else
+		new_fid->fd	= open(rel_to_abs_root(new_fid->path), omode2uflags(topen->mode));
+
+	*outlen = VIRTIO_P9_HDR_LEN + sizeof(*ropen);
+	set_p9msg_hdr(outmsg, *outlen, P9_ROPEN, msg->tag);
+
+	return true;
+}
+
+static bool virtio_p9_create(struct p9_msg *msg, u32 len, struct iovec *iov, u32 *outlen)
+{
+	struct p9_msg *outmsg		= iov[0].iov_base;
+	struct p9_tcreate *tcreate	= (struct p9_tcreate *)msg->msg;
+	struct p9_rcreate *rcreate	= (struct p9_rcreate *)outmsg->msg;
+	struct p9_fid *fid		= &p9dev.fids[tcreate->fid];
+	struct stat st;
+	char new_file[PATH_MAX];
+	u8 mode;
+	u32 perm;
+
+	rcreate->iounit = 0;
+
+	/* Get last byte of the variable length struct */
+	mode = *((u8 *)msg + msg->size - 1);
+	perm = *(u32 *)((u8 *)msg + msg->size - 5);
+
+	sprintf(new_file, "%s/%.*s", fid->path, tcreate->name.len, (char *)&tcreate->name.str);
+	strcpy(fid->path, new_file);
+
+	close_fid(tcreate->fid);
+
+	if (perm & P9_DMDIR) {
+		mkdir(rel_to_abs_root(new_file), perm & 0xFFFF);
+		fid->dir = opendir(rel_to_abs_root(new_file));
+		fid->is_dir = 1;
+	} else {
+		fid->fd = open(rel_to_abs_root(new_file), omode2uflags(mode) | O_CREAT, perm & 0xFFFF);
+	}
+
+	if (stat(rel_to_abs_root(fid->path), &st) < 0)
+		return false;
+
+	st2qid(&st, &rcreate->qid);
+
+	*outlen = VIRTIO_P9_HDR_LEN + sizeof(*rcreate);
+	set_p9msg_hdr(outmsg, *outlen, P9_RCREATE, msg->tag);
+
+	return true;
+}
+
+static bool virtio_p9_walk(struct p9_msg *msg, u32 len, struct iovec *iov, u32 *outlen)
+{
+	struct p9_msg *outmsg	= iov[0].iov_base;
+	struct p9_twalk *twalk	= (struct p9_twalk *)msg->msg;
+	struct p9_rwalk *rwalk	= (struct p9_rwalk *)outmsg->msg;
+	struct p9_str *str	= twalk->wnames;
+	struct p9_fid *new_fid	= &p9dev.fids[twalk->newfid];
+	u8 i;
+
+	rwalk->nwqid = 0;
+	if (twalk->nwname) {
+		struct p9_fid *fid = &p9dev.fids[twalk->fid];
+		for (i = 0; i < twalk->nwname; i++) {
+			char tmp[PATH_MAX] = {0};
+			struct stat st;
+
+			/* Format the new path we're 'walk'ing into */
+			sprintf(tmp, "%s/%.*s", fid->path, str->len, (char *)&str->str);
+
+			if (stat(rel_to_abs_root(tmp), &st) < 0)
+				break;
+
+			st2qid(&st, &rwalk->wqids[i]);
+			new_fid->is_dir = S_ISDIR(st.st_mode);
+			strcpy(new_fid->path, tmp);
+			new_fid->fid = twalk->newfid;
+			rwalk->nwqid++;
+		}
+	} else {
+		*new_fid	= p9dev.fids[twalk->fid];
+		new_fid->fid	= twalk->newfid;
+	}
+
+	*outlen = VIRTIO_P9_HDR_LEN + sizeof(u16) + sizeof(struct p9_qid) * rwalk->nwqid;
+	set_p9msg_hdr(outmsg, *outlen, P9_RWALK, msg->tag);
+
+	return true;
+}
+
+static bool virtio_p9_attach(struct p9_msg *msg, u32 len, struct iovec *iov, u32 *outlen)
+{
+	struct p9_msg *outmsg = iov[0].iov_base;
+	struct p9_rattach *rattach = (struct p9_rattach *)outmsg->msg;
+	struct p9_tattach *tattach = (struct p9_tattach *)msg->msg;
+	struct stat st;
+	struct p9_fid *fid;
+	u32 i;
+
+	/* Reset everything */
+	for (i = 0; i < VIRTIO_P9_MAX_FID; i++)
+		p9dev.fids[i].fid = P9_NOFID;
+
+	if (stat(rel_to_abs_root("/"), &st) < 0)
+		return false;
+
+	st2qid(&st, &rattach->qid);
+
+	fid = &p9dev.fids[tattach->fid];
+	fid->fid = tattach->fid;
+	fid->is_dir = 1;
+	strcpy(fid->path, "/");
+
+	*outlen = VIRTIO_P9_HDR_LEN + sizeof(*rattach);
+	set_p9msg_hdr(outmsg, *outlen, P9_RATTACH, msg->tag);
+
+	return true;
+}
+
+static u32 virtio_p9_fill_stat(const char *name, struct stat *st, struct p9_rstat *rstat)
+{
+	struct p9_str *str;
+
+	rstat->stat.type = 0;
+	rstat->stat.dev = 0;
+	st2qid(st, &rstat->stat.qid);
+	rstat->stat.mode = st->st_mode;
+	rstat->stat.length = st->st_size;
+	if (S_ISDIR(st->st_mode)) {
+		rstat->stat.length = 0;
+		rstat->stat.mode |= P9_DMDIR;
+	}
+
+	rstat->stat.atime = st->st_atime;
+	rstat->stat.mtime = st->st_mtime;
+
+	str = (struct p9_str *)&rstat->stat.name;
+	str->len = strlen(name);
+	memcpy(&str->str, name, str->len);
+	str = (void *)str + str->len + sizeof(u16);
+
+	/* TODO: Pass usernames to the client */
+	str->len = 0;
+	str = (void *)str + sizeof(u16);
+	str->len = 0;
+	str = (void *)str + sizeof(u16);
+	str->len = 0;
+	str = (void *)str + sizeof(u16);
+
+	/* We subtract a u16 here because rstat->size doesn't include rstat->size itself */
+	rstat->stat.size = (void *)str - (void *)&rstat->stat - sizeof(u16);
+
+	return rstat->stat.size + sizeof(u16);
+}
+
+static bool virtio_p9_read(struct p9_msg *msg, u32 len, struct iovec *iov, int iovcnt, u32 *outlen)
+{
+	struct p9_msg *outmsg	= iov[0].iov_base;
+	struct p9_tread *tread	= (struct p9_tread *)msg->msg;
+	struct p9_rread *rread	= (struct p9_rread *)outmsg->msg;
+	struct p9_rstat *rstat	= (struct p9_rstat *)iov[1].iov_base;
+	struct p9_fid *fid	= &p9dev.fids[tread->fid];
+	struct stat st;
+
+	rread->count = 0;
+
+	if (fid->is_dir) {
+		/* If reading a dir, fill the buffer with p9_stat entries */
+		struct dirent *cur = readdir(fid->dir);
+		while (cur) {
+			u32 read;
+			stat(rel_to_abs_root(cur->d_name), &st);
+			read = virtio_p9_fill_stat(cur->d_name, &st, rstat);
+			rread->count += read;
+			rstat = (void *)rstat + read;
+			cur = readdir(fid->dir);
+		}
+	} else {
+		/* When reading data, First iov buffer holds the header */
+		iov++;
+		iovcnt--;
+		rread->count = preadv(fid->fd, iov, iovcnt, tread->offset);
+		if (rread->count > tread->count)
+			rread->count = tread->count;
+	}
+
+	*outlen = VIRTIO_P9_HDR_LEN + sizeof(u32) + rread->count;
+	set_p9msg_hdr(outmsg, *outlen, P9_RREAD, msg->tag);
+
+	return true;
+}
+
+static bool virtio_p9_stat(struct p9_msg *msg, u32 len, struct iovec *iov, u32 *outlen)
+{
+	struct p9_msg *outmsg = iov[0].iov_base;
+	struct p9_tstat *tstat = (struct p9_tstat *)msg->msg;
+
+	/*
+	 * HACK: For some reason the p9 virtio transport reads a u16 and discards
+	 * it before reading the p9_rstat struct. I couldn't find a logical reason for
+	 * that, so we just add an extra u16 before the struct.
+	 */
+	struct p9_rstat *rstat = (struct p9_rstat *)(outmsg->msg + sizeof(u16));
+	struct stat st;
+	struct p9_fid *fid = &p9dev.fids[tstat->fid];
+	u32 ret;
+
+	if (stat(rel_to_abs_root(fid->path), &st) < 0)
+		return false;
+
+	ret = virtio_p9_fill_stat(fid->path, &st, rstat);
+
+	*outlen = VIRTIO_P9_HDR_LEN + ret + sizeof(u16) * 2;
+	set_p9msg_hdr(outmsg, *outlen, P9_RSTAT, msg->tag);
+	return true;
+}
+
+static bool virtio_p9_wstat(struct p9_msg *msg, u32 len, struct iovec *iov, u32 *outlen)
+{
+	struct p9_msg *outmsg = iov[0].iov_base;
+	struct p9_twstat *twstat = (struct p9_twstat *)msg->msg;
+	struct p9_str *str;
+	struct p9_fid *fid = &p9dev.fids[twstat->fid];
+	int res;
+
+	if (twstat->stat.length != -1UL)
+		res = ftruncate(fid->fd, twstat->stat.length);
+
+	if (twstat->stat.mode != -1U)
+		chmod(rel_to_abs_root(fid->path), twstat->stat.mode & 0xFFFF);
+
+	str = (void *)&twstat->stat.name + sizeof(u16);
+	if (str->len > 0) {
+		char new_name[PATH_MAX] = {0};
+		char *last_dir = strrchr(fid->path, '/');
+
+		/* We need to get the full file name out of twstat->name */
+		if (last_dir)
+			strncpy(new_name, fid->path, last_dir - fid->path + 1);
+
+		memcpy(new_name + strlen(new_name), &str->str, str->len);
+		sprintf(fid->path, "%s", new_name);
+
+		/* fid is reused for the new file */
+		strcpy(new_name, rel_to_abs_root(new_name));
+		rename(rel_to_abs_root(fid->path), new_name);
+	}
+
+	*outlen = VIRTIO_P9_HDR_LEN;
+	set_p9msg_hdr(outmsg, *outlen, P9_RWSTAT, msg->tag);
+	return true;
+}
+
+static bool virtio_p9_remove(struct p9_msg *msg, u32 len, struct iovec *iov, u32 *outlen)
+{
+	struct p9_msg *outmsg = iov[0].iov_base;
+	struct p9_tremove *tremove = (struct p9_tremove *)msg->msg;
+	struct p9_fid *fid = &p9dev.fids[tremove->fid];
+
+	close_fid(tremove->fid);
+	if (fid->is_dir)
+		rmdir(rel_to_abs_root(fid->path));
+	else
+		unlink(rel_to_abs_root(fid->path));
+
+	*outlen = VIRTIO_P9_HDR_LEN;
+	set_p9msg_hdr(outmsg, *outlen, P9_RREMOVE, msg->tag);
+	return true;
+}
+
+static bool virtio_p9_write(struct p9_msg *msg, u32 len, struct iovec *iov, int iovcnt, u32 *outlen)
+{
+	struct p9_msg *outmsg;
+	struct p9_rwrite *rwrite;
+	struct p9_twrite *twrite = (struct p9_twrite *)msg->msg;
+	struct p9_fid *fid = &p9dev.fids[twrite->fid];
+
+	if (iovcnt == 1) {
+		outmsg = iov[0].iov_base;
+		rwrite = (struct p9_rwrite *)outmsg->msg;
+		rwrite->count = pwrite(fid->fd, &twrite->data, twrite->count, twrite->offset);
+	} else {
+		outmsg = iov[2].iov_base;
+		rwrite = (struct p9_rwrite *)outmsg->msg;
+		rwrite->count = pwrite(fid->fd, iov[1].iov_base, twrite->count, twrite->offset);
+	}
+
+	*outlen = VIRTIO_P9_HDR_LEN + sizeof(u32);
+	set_p9msg_hdr(outmsg, *outlen, P9_RWRITE, msg->tag);
+
+	return true;
+}
+
+static bool virtio_p9_do_io_request(struct kvm *kvm, struct virt_queue *queue)
+{
+	struct iovec iov[VIRTIO_P9_QUEUE_SIZE];
+	u16 out, in, head;
+	struct p9_msg *msg;
+	u32 len = 0;
+
+	head		= virt_queue__get_iov(queue, iov, &out, &in, kvm);
+	msg		= iov[0].iov_base;
+
+	switch (msg->cmd) {
+	case P9_TVERSION:
+		virtio_p9_version(msg, iov[0].iov_len, iov+1, &len);
+		break;
+	case P9_TATTACH:
+		virtio_p9_attach(msg, iov[0].iov_len, iov+1, &len);
+		break;
+	case P9_TSTAT:
+		virtio_p9_stat(msg, iov[0].iov_len, iov+1, &len);
+		break;
+	case P9_TCLUNK:
+		virtio_p9_clunk(msg, iov[0].iov_len, iov+1, &len);
+		break;
+	case P9_TWALK:
+		virtio_p9_walk(msg, iov[0].iov_len, iov+1, &len);
+		break;
+	case P9_TOPEN:
+		virtio_p9_open(msg, iov[0].iov_len, iov+1, &len);
+		break;
+	case P9_TREAD:
+		virtio_p9_read(msg, iov[0].iov_len, iov+1, in, &len);
+		break;
+	case P9_TCREATE:
+		virtio_p9_create(msg, iov[0].iov_len, iov+1, &len);
+		break;
+	case P9_TWSTAT:
+		virtio_p9_wstat(msg, iov[0].iov_len, iov+1, &len);
+		break;
+	case P9_TREMOVE:
+		virtio_p9_remove(msg, iov[0].iov_len, iov+1, &len);
+		break;
+	case P9_TWRITE:
+		virtio_p9_write(msg, iov[0].iov_len, iov+1, out, &len);
+		break;
+	default:
+		printf("Unsupported P9 message type: %u\n", msg->cmd);
+		break;
+	}
+	virt_queue__set_used_elem(queue, head, len);
+
+	return true;
+}
+
+static void virtio_p9_do_io(struct kvm *kvm, void *param)
+{
+	struct virt_queue *vq = param;
+
+	while (virt_queue__available(vq)) {
+		virtio_p9_do_io_request(kvm, vq);
+		virt_queue__trigger_irq(vq, virtio_p9_pci_device.irq_line, &p9dev.isr, kvm);
+	}
+}
+
+static bool virtio_p9_pci_io_out(struct kvm *kvm, u16 port, void *data, int size, u32 count)
+{
+	unsigned long offset;
+	bool ret = true;
+
+	offset		= port - IOPORT_VIRTIO_P9;
+
+	switch (offset) {
+	case VIRTIO_MSI_QUEUE_VECTOR:
+	case VIRTIO_PCI_GUEST_FEATURES:
+		break;
+	case VIRTIO_PCI_QUEUE_PFN: {
+		struct virt_queue *queue;
+		void *p;
+
+		queue			= &p9dev.vqs[p9dev.queue_selector];
+		queue->pfn		= ioport__read32(data);
+		p			= guest_pfn_to_host(kvm, queue->pfn);
+
+		vring_init(&queue->vring, VIRTIO_P9_QUEUE_SIZE, p, VIRTIO_PCI_VRING_ALIGN);
+
+		p9dev.jobs[p9dev.queue_selector] = thread_pool__add_job(kvm, virtio_p9_do_io, queue);
+
+		break;
+	}
+	case VIRTIO_PCI_QUEUE_SEL:
+		p9dev.queue_selector	= ioport__read16(data);
+		break;
+	case VIRTIO_PCI_QUEUE_NOTIFY: {
+		u16 queue_index;
+		queue_index		= ioport__read16(data);
+		thread_pool__do_job(p9dev.jobs[queue_index]);
+		break;
+	}
+	case VIRTIO_PCI_STATUS:
+		p9dev.status		= ioport__read8(data);
+		break;
+	case VIRTIO_MSI_CONFIG_VECTOR:
+		p9dev.config_vector	= VIRTIO_MSI_NO_VECTOR;
+		break;
+	default:
+		ret			= false;
+		break;
+	};
+
+	return ret;
+}
+
+static struct ioport_operations virtio_p9_io_ops = {
+	.io_in				= virtio_p9_pci_io_in,
+	.io_out				= virtio_p9_pci_io_out,
+};
+
+void virtio_9p__init(struct kvm *kvm, const char *root)
+{
+	u8 pin, line, dev;
+
+	p9dev.config = calloc(1, sizeof(*p9dev.config) + sizeof(VIRTIO_P9_TAG));
+	if (p9dev.config == NULL)
+		return;
+
+	strcpy(p9dev.root_dir, root);
+
+	p9dev.config->tag_len = strlen(VIRTIO_P9_TAG);
+	memcpy(p9dev.config->tag, VIRTIO_P9_TAG, strlen(VIRTIO_P9_TAG));
+	p9dev.features |= 1 << VIRTIO_9P_MOUNT_TAG;
+
+	if (irq__register_device(VIRTIO_ID_9P, &dev, &pin, &line) < 0)
+		return;
+
+	virtio_p9_pci_device.irq_pin	= pin;
+	virtio_p9_pci_device.irq_line	= line;
+	pci__register(&virtio_p9_pci_device, dev);
+
+	ioport__register(IOPORT_VIRTIO_P9, &virtio_p9_io_ops, IOPORT_VIRTIO_P9_SIZE);
+}
-- 
1.7.5.rc3

Re: [PATCH 2/2] kvm tools: Add virtio-9p

[Ingo Molnar]

* Sasha Levin <levinsasha928@gmail.com> wrote:

> 3. Within the guest, mount the fs:
> mount -t 9p -otrans=virtio kvm_9p <local_dir> -oversion=9p2000
> This will mount the 9p server to local_dir.

Really cool!

> Still todo (but can live without):
>  - Multiple virtio-9p devices.
>  - Ugly hack in virtio_p9_stat() (See desc in code).
>  - Update atime/mtime in p9_wstat, not really needed.
>  - Pass usernames in p9_stat, not really needed and not really sure how
> p9 expects to handle them.

is root-9p possible? I.e. ideally i'd like to have no image at all - just a 
guest kernel and a directory hierarchy for the guest filesystem.

	Ingo

Re: [PATCH 2/2] kvm tools: Add virtio-9p

[Sasha Levin]

On Tue, 2011-05-17 at 20:40 +0200, Ingo Molnar wrote:
> * Sasha Levin <levinsasha928@gmail.com> wrote:
> 
> > 3. Within the guest, mount the fs:
> > mount -t 9p -otrans=virtio kvm_9p <local_dir> -oversion=9p2000
> > This will mount the 9p server to local_dir.
> 
> Really cool!

Thanks!

> is root-9p possible? I.e. ideally i'd like to have no image at all - just a 
> guest kernel and a directory hierarchy for the guest filesystem.

>From what I can tell, not currently.

'kvm_9p' isn't created as a device under /dev, it's just a name used
internally by 9pnet_virtio (and located under sysfs).

I couldn't figure out which params the kernel would expect to boot using
9p over virtio (theres no device name to begin with).

I've also couldn't find anything that suggested it's possible to boot
using virtio-9p as rootfs.


-- 

Sasha.

Re: [PATCH 2/2] kvm tools: Add virtio-9p

[Ingo Molnar]

* Sasha Levin <levinsasha928@gmail.com> wrote:

> On Tue, 2011-05-17 at 20:40 +0200, Ingo Molnar wrote:
> > * Sasha Levin <levinsasha928@gmail.com> wrote:
> > 
> > > 3. Within the guest, mount the fs:
> > > mount -t 9p -otrans=virtio kvm_9p <local_dir> -oversion=9p2000
> > > This will mount the 9p server to local_dir.
> > 
> > Really cool!
> 
> Thanks!
> 
> > is root-9p possible? I.e. ideally i'd like to have no image at all - just a 
> > guest kernel and a directory hierarchy for the guest filesystem.
> 
> >From what I can tell, not currently.
> 
> 'kvm_9p' isn't created as a device under /dev, it's just a name used
> internally by 9pnet_virtio (and located under sysfs).
> 
> I couldn't figure out which params the kernel would expect to boot using
> 9p over virtio (theres no device name to begin with).
> 
> I've also couldn't find anything that suggested it's possible to boot
> using virtio-9p as rootfs.

This needs guest kernel support, in form of a small amount of 9p specific 
mounting glue code that the guest kernel will run if either a .config option is 
set or a boot commandline is specified.

Such a thing already exists for another networked filesystem: NFS, so i would 
suggest looking at the CONFIG_ROOT_NFS=y glue in Linux, i think 9p mounting 
support would be welcome!

Thanks,

	Ingo

Re: [PATCH 2/2] kvm tools: Add virtio-9p

[Sasha Levin]

On Tue, 2011-05-17 at 22:08 +0300, Sasha Levin wrote:
> 'kvm_9p' isn't created as a device under /dev, it's just a name used
> internally by 9pnet_virtio (and located under sysfs).
> 
> I couldn't figure out which params the kernel would expect to boot using
> 9p over virtio (theres no device name to begin with).
> 
> I've also couldn't find anything that suggested it's possible to boot
> using virtio-9p as rootfs.

Ignore that.

Naming the virtio transport "/dev/root" and passing proper params to the
kernel makes it work:

[    1.844983] VFS: Mounted root (9p filesystem) on device 0:11.

I'll make some changes to the virtio-9p patch to make it easier for the
user to do that.

-- 

Sasha.

Re: [PATCH 2/2] kvm tools: Add virtio-9p

[Eric Van Hensbergen]

On Tue, May 17, 2011 at 3:27 PM, Sasha Levin <levinsasha928@gmail.com> wrote:
> On Tue, 2011-05-17 at 22:08 +0300, Sasha Levin wrote:
>> 'kvm_9p' isn't created as a device under /dev, it's just a name used
>> internally by 9pnet_virtio (and located under sysfs).
>>
>> I couldn't figure out which params the kernel would expect to boot using
>> 9p over virtio (theres no device name to begin with).
>>
>> I've also couldn't find anything that suggested it's possible to boot
>> using virtio-9p as rootfs.
>
> Ignore that.
>
> Naming the virtio transport "/dev/root" and passing proper params to the
> kernel makes it work:
>
> [    1.844983] VFS: Mounted root (9p filesystem) on device 0:11.
>
> I'll make some changes to the virtio-9p patch to make it easier for the
> user to do that.
>

This is really sweet.  Thanks for beating me to the punch of porting
the 9p support to kvm tools.

> - Multiple virtio-9p devices.

This should be pretty straightforward.

> - Ugly hack in virtio_p9_stat() (See desc in code).
>       /*
>+        * HACK: For some reason the p9 virtio transport reads a u16 and discards
>+        * it before reading the p9_rstat struct. I couldn't find a logical reason for
>+        * that, so we just add an extra u16 before the struct.
>+        */

This is part of the protocol spec (from
http://ericvh.github.com/9p-rfc/rfc9p2000.html#anchor32):
"To make the contents of a directory, such as returned by read(5),
easy to parse, each directory entry begins with a size field. For
consistency, the entries in Twstat and Rstat messages also contain
their size, which means the size appears twice. For example, the Rstat
message is formatted as ``(4+1+2+2+n)[4] Rstat tag[2] n[2] (n-2)[2]
type[2] dev[4]...,'' where n is the value returned by convD2M."
It's appropriate to duplicate the size.  I think the Linux client
ignores it, but others implementations may complain.

> - Update atime/mtime in p9_wstat, not really needed.

The underlying storage may handle this for you, I think 9p avoids
updating atime by default, at least in caching scenarios -- too much
unnecessary protocol traffic.

> - Pass usernames in p9_stat, not really needed and not really sure how p9 expects to handle them.

The username, group name issue is one of the principle reasons behind
the extended protocol operations (.u and .L) -- of course, if there
was a Plan 9 or Inferno guest they would be quite happy with the
usernames, but Linux (and other UNIX variants) will want the ids.  To
really keep things simple we could add a client option that would let
you pass the various ids as strings.  Although no doubt folks will
want the other extensions (symlinks, links, device nodes, etc.) before
long.  When we built the qemu server for .L, the team tried to keep
everything in a library, but there is some entanglement with the qemu
APIs -- it'd be nice if we could reuse that code here, maybe we need
an abstract glue layer so that the core code can be used by both the
kvm tool and qemu.  I'm copy the lead of that team on this message
just so he's aware how far you've come.

         -eric

Re: [PATCH 2/2] kvm tools: Add virtio-9p

[Pekka Enberg]

On Tue, May 17, 2011 at 9:35 PM, Sasha Levin <levinsasha928@gmail.com> wrote:
> Overview:
> 9p allows for simple RPC based resource sharing over
> different transports (in our case, virtio).
>
> This is the implementation of (most of) the original
> 9p2000 protocol, without the .u or the .l extensions.
>
> How to use:
> 1. Make sure kernel is compiled with:
>    CONFIG_NET_9P=y
>    CONFIG_NET_9P_VIRTIO=y
>    CONFIG_NET_9P_DEBUG=y (At least until code is stable)
>    CONFIG_9P_FS=y
>
> 2. Start KVM with '--virtio-9p <dirname>'. What happens now is that
> a virtio transport with the name 'kvm_9p' is created. The server side
> of the transport maps dirname to the root of the file system.
>
> 3. Within the guest, mount the fs:
> mount -t 9p -otrans=virtio kvm_9p <local_dir> -oversion=9p2000
> This will mount the 9p server to local_dir.

This is really cool, Sasha! I'd like to see host "/" mounted as
"/host" automatically in the guest. If that's too radical, we could go
for mounting $HOME. I guess it's pretty trivial to do on the
hypervisor side but can we do that for unmodified guests (not
necessarily unmodified guest kernels, though)?

                         Pekka

Re: [PATCH 2/2] kvm tools: Add virtio-9p

[Ingo Molnar]

* Eric Van Hensbergen <ericvh@gmail.com> wrote:

> > - Update atime/mtime in p9_wstat, not really needed.
> 
> The underlying storage may handle this for you, I think 9p avoids
> updating atime by default, at least in caching scenarios -- too much
> unnecessary protocol traffic.

Yeah, atime is absolutely painful all around - just don't do it by default and 
maybe allow it via some option. Very little userspace depends on it and almost 
none will break outright, there is a large number of filesystems that do not do 
any (or do a poor) atime update.

So if atimes are not provided straight away it will be very clear from the 
beginning that atime isnt something that will be there by default.

Thanks,

	Ingo

Re: [PATCH 2/2] kvm tools: Add virtio-9p

[Sasha Levin]

On Tue, 2011-05-17 at 20:18 -0500, Eric Van Hensbergen wrote:
> On Tue, May 17, 2011 at 3:27 PM, Sasha Levin <levinsasha928@gmail.com> wrote:
> > On Tue, 2011-05-17 at 22:08 +0300, Sasha Levin wrote:
> >> 'kvm_9p' isn't created as a device under /dev, it's just a name used
> >> internally by 9pnet_virtio (and located under sysfs).
> >>
> >> I couldn't figure out which params the kernel would expect to boot using
> >> 9p over virtio (theres no device name to begin with).
> >>
> >> I've also couldn't find anything that suggested it's possible to boot
> >> using virtio-9p as rootfs.
> >
> > Ignore that.
> >
> > Naming the virtio transport "/dev/root" and passing proper params to the
> > kernel makes it work:
> >
> > [    1.844983] VFS: Mounted root (9p filesystem) on device 0:11.
> >
> > I'll make some changes to the virtio-9p patch to make it easier for the
> > user to do that.
> >
> 
> This is really sweet.  Thanks for beating me to the punch of porting
> the 9p support to kvm tools.

Clear RFC and good source code to refer to within 9p modules made this
easy (and fun) :)

> > - Multiple virtio-9p devices.
> 
> This should be pretty straightforward.

Yes, Most of the work here is within the kvm tool.

> > - Ugly hack in virtio_p9_stat() (See desc in code).
> >       /*
> >+        * HACK: For some reason the p9 virtio transport reads a u16 and discards
> >+        * it before reading the p9_rstat struct. I couldn't find a logical reason for
> >+        * that, so we just add an extra u16 before the struct.
> >+        */
> 
> This is part of the protocol spec (from
> http://ericvh.github.com/9p-rfc/rfc9p2000.html#anchor32):
> "To make the contents of a directory, such as returned by read(5),
> easy to parse, each directory entry begins with a size field. For
> consistency, the entries in Twstat and Rstat messages also contain
> their size, which means the size appears twice. For example, the Rstat
> message is formatted as ``(4+1+2+2+n)[4] Rstat tag[2] n[2] (n-2)[2]
> type[2] dev[4]...,'' where n is the value returned by convD2M."
> It's appropriate to duplicate the size.  I think the Linux client
> ignores it, but others implementations may complain.

Thanks for the explanation!
Yes, Linux implementation just throws it away - which was what confused
me initially.
Why not add a u16 to the beginning of 'struct p9_rstat'?

> > - Update atime/mtime in p9_wstat, not really needed.
> 
> The underlying storage may handle this for you, I think 9p avoids
> updating atime by default, at least in caching scenarios -- too much
> unnecessary protocol traffic.

My assumption was that the storage I read/write to will take care of it
for me, and unless it bothers anyone in the future I'll assume it's
doing a good job at it.

> > - Pass usernames in p9_stat, not really needed and not really sure how p9 expects to handle them.
> 
> The username, group name issue is one of the principle reasons behind
> the extended protocol operations (.u and .L) -- of course, if there
> was a Plan 9 or Inferno guest they would be quite happy with the
> usernames, but Linux (and other UNIX variants) will want the ids.  To
> really keep things simple we could add a client option that would let
> you pass the various ids as strings.  Although no doubt folks will
> want the other extensions (symlinks, links, device nodes, etc.) before
> long.  When we built the qemu server for .L, the team tried to keep
> everything in a library, but there is some entanglement with the qemu
> APIs -- it'd be nice if we could reuse that code here, maybe we need
> an abstract glue layer so that the core code can be used by both the
> kvm tool and qemu.  I'm copy the lead of that team on this message
> just so he's aware how far you've come.

I'd prefer using a tested lib which also implements .L over what we have
now, assuming it's not tangled into qemu too hard.


> 
>          -eric


-- 

Sasha.

Re: [PATCH 2/2] kvm tools: Add virtio-9p

[Sasha Levin]

On Wed, 2011-05-18 at 09:38 +0300, Pekka Enberg wrote:
> On Tue, May 17, 2011 at 9:35 PM, Sasha Levin <levinsasha928@gmail.com> wrote:
> > Overview:
> > 9p allows for simple RPC based resource sharing over
> > different transports (in our case, virtio).
> >
> > This is the implementation of (most of) the original
> > 9p2000 protocol, without the .u or the .l extensions.
> >
> > How to use:
> > 1. Make sure kernel is compiled with:
> >    CONFIG_NET_9P=y
> >    CONFIG_NET_9P_VIRTIO=y
> >    CONFIG_NET_9P_DEBUG=y (At least until code is stable)
> >    CONFIG_9P_FS=y
> >
> > 2. Start KVM with '--virtio-9p <dirname>'. What happens now is that
> > a virtio transport with the name 'kvm_9p' is created. The server side
> > of the transport maps dirname to the root of the file system.
> >
> > 3. Within the guest, mount the fs:
> > mount -t 9p -otrans=virtio kvm_9p <local_dir> -oversion=9p2000
> > This will mount the 9p server to local_dir.
> 
> This is really cool, Sasha! I'd like to see host "/" mounted as
> "/host" automatically in the guest. If that's too radical, we could go
> for mounting $HOME. I guess it's pretty trivial to do on the
> hypervisor side but can we do that for unmodified guests (not
> necessarily unmodified guest kernels, though)?
> 
>                          Pekka

I'm not sure how to do the guest part automatically, it's just a simple
mount command - but I don't see how we can do it in a simple manner.

-- 

Sasha.

Re: [PATCH 2/2] kvm tools: Add virtio-9p

[Pekka Enberg]

On Wed, May 18, 2011 at 1:35 PM, Sasha Levin <levinsasha928@gmail.com> wrote:
> I'm not sure how to do the guest part automatically, it's just a simple
> mount command - but I don't see how we can do it in a simple manner.

IIRC, Ingo suggested a kernel config option - a kernel parameter might
also work. Eric, Ingo, thoughts?

Re: [PATCH 2/2] kvm tools: Add virtio-9p

[Sasha Levin]

On Wed, 2011-05-18 at 13:38 +0300, Pekka Enberg wrote:
> On Wed, May 18, 2011 at 1:35 PM, Sasha Levin <levinsasha928@gmail.com> wrote:
> > I'm not sure how to do the guest part automatically, it's just a simple
> > mount command - but I don't see how we can do it in a simple manner.
> 
> IIRC, Ingo suggested a kernel config option - a kernel parameter might
> also work. Eric, Ingo, thoughts?

Ingo suggested kernel config option to allow booting from 9p (similarly
to NFS), but thats not needed at the moment - we can boot 9p just as any
other fs if we name our virtio transport right.

We can add a more generic kernel parameter that will mount simple
filesystem[s] after mounting rootfs (something like the root= option,
but for non-root systems).

-- 

Sasha.

Re: [PATCH 2/2] kvm tools: Add virtio-9p

[Ingo Molnar]

* Sasha Levin <levinsasha928@gmail.com> wrote:

> On Wed, 2011-05-18 at 13:38 +0300, Pekka Enberg wrote:
> > On Wed, May 18, 2011 at 1:35 PM, Sasha Levin <levinsasha928@gmail.com> wrote:
> > > I'm not sure how to do the guest part automatically, it's just a simple
> > > mount command - but I don't see how we can do it in a simple manner.
> > 
> > IIRC, Ingo suggested a kernel config option - a kernel parameter might
> > also work. Eric, Ingo, thoughts?
> 
> Ingo suggested kernel config option to allow booting from 9p (similarly
> to NFS), but thats not needed at the moment - we can boot 9p just as any
> other fs if we name our virtio transport right.
> 
> We can add a more generic kernel parameter that will mount simple
> filesystem[s] after mounting rootfs (something like the root= option,
> but for non-root systems).

Correct, and yes it should be a separate thing (and we still want it): just 
like there's a .config option to mount devtmpfs under /dev automatically, see 
CONFIG_DEVTMPFS=y.

Thanks,

	Ingo

Re: [PATCH 2/2] kvm tools: Add virtio-9p

[Sasha Levin]

On Tue, 2011-05-17 at 23:27 +0300, Sasha Levin wrote:
> On Tue, 2011-05-17 at 22:08 +0300, Sasha Levin wrote:
> > 'kvm_9p' isn't created as a device under /dev, it's just a name used
> > internally by 9pnet_virtio (and located under sysfs).
> > 
> > I couldn't figure out which params the kernel would expect to boot using
> > 9p over virtio (theres no device name to begin with).
> > 
> > I've also couldn't find anything that suggested it's possible to boot
> > using virtio-9p as rootfs.
> 
> Ignore that.
> 
> Naming the virtio transport "/dev/root" and passing proper params to the
> kernel makes it work:
> 
> [    1.844983] VFS: Mounted root (9p filesystem) on device 0:11.
> 
> I'll make some changes to the virtio-9p patch to make it easier for the
> user to do that.
> 

Just to sum the '9p bootability' discussion, It is possible to boot from
virtio-9p devices. The sample disk image provided by qemu (the one we
link in our README) boots just fine.

I've had to use a 2.6.39 kernel when booting, using the 2.6.37 kernel
which we have in kvm tools tree doesn't work. I haven't investigated why
yet.

Transport name must be called "/dev/root". Both when defining it for the
virtio transport and in the kernel root= parameter. Changing either of
them leads to: '9p: no channels available'.

Here is the command line I've used (rootfs/ is a mount of
'linux-0.2.img'):
./kvm run -m 256 --virtio-9p rootfs/ --params "root=/dev/root
rootflags=rw,trans=virtio,version=9p2000,debug=0x00 rootfstype=9p rw"
-k /boot/bzImage

When trying to boot a distribution rootfs we get a lot of symbolic link
and file locking errors, since neither of those is supported by legacy
9p2000 - thats understandable. It just prevents from almost anything
more complicated than simple command line from working properly.

-- 

Sasha.

Re: [PATCH 2/2] kvm tools: Add virtio-9p

[Ingo Molnar]

* Sasha Levin <levinsasha928@gmail.com> wrote:

> When trying to boot a distribution rootfs we get a lot of symbolic link and 
> file locking errors, since neither of those is supported by legacy 9p2000 - 
> thats understandable. It just prevents from almost anything more complicated 
> than simple command line from working properly.

Just curious: are there plans to improving this situation in the future?

Thanks,

	Ingo

Re: [PATCH 2/2] kvm tools: Add virtio-9p

[Sasha Levin]

On Wed, 2011-05-18 at 14:06 +0200, Ingo Molnar wrote:
> * Sasha Levin <levinsasha928@gmail.com> wrote:
> 
> > When trying to boot a distribution rootfs we get a lot of symbolic link and 
> > file locking errors, since neither of those is supported by legacy 9p2000 - 
> > thats understandable. It just prevents from almost anything more complicated 
> > than simple command line from working properly.
> 
> Just curious: are there plans to improving this situation in the future?

Current implementation can be extended to support 9p2000.u extensions,
RFC simplicity suggests it should be pretty simple.

-- 

Sasha.

Re: [PATCH 2/2] kvm tools: Add virtio-9p

[Venkateswararao Jujjuri]

On 05/18/2011 02:05 AM, Sasha Levin wrote:
> On Tue, 2011-05-17 at 20:18 -0500, Eric Van Hensbergen wrote:
>> On Tue, May 17, 2011 at 3:27 PM, Sasha Levin<levinsasha928@gmail.com>  wrote:
>>> On Tue, 2011-05-17 at 22:08 +0300, Sasha Levin wrote:
>>>> 'kvm_9p' isn't created as a device under /dev, it's just a name used
>>>> internally by 9pnet_virtio (and located under sysfs).
>>>>
>>>> I couldn't figure out which params the kernel would expect to boot using
>>>> 9p over virtio (theres no device name to begin with).
>>>>
>>>> I've also couldn't find anything that suggested it's possible to boot
>>>> using virtio-9p as rootfs.
>>> Ignore that.
>>>
>>> Naming the virtio transport "/dev/root" and passing proper params to the
>>> kernel makes it work:
>>>
>>> [    1.844983] VFS: Mounted root (9p filesystem) on device 0:11.
>>>
>>> I'll make some changes to the virtio-9p patch to make it easier for the
>>> user to do that.
>>>
>> This is really sweet.  Thanks for beating me to the punch of porting
>> the 9p support to kvm tools.
> Clear RFC and good source code to refer to within 9p modules made this
> easy (and fun) :)
>
>>> - Multiple virtio-9p devices.
>> This should be pretty straightforward.
> Yes, Most of the work here is within the kvm tool.
>
>>> - Ugly hack in virtio_p9_stat() (See desc in code).
>>>        /*
>>> +        * HACK: For some reason the p9 virtio transport reads a u16 and discards
>>> +        * it before reading the p9_rstat struct. I couldn't find a logical reason for
>>> +        * that, so we just add an extra u16 before the struct.
>>> +        */
>> This is part of the protocol spec (from
>> http://ericvh.github.com/9p-rfc/rfc9p2000.html#anchor32):
>> "To make the contents of a directory, such as returned by read(5),
>> easy to parse, each directory entry begins with a size field. For
>> consistency, the entries in Twstat and Rstat messages also contain
>> their size, which means the size appears twice. For example, the Rstat
>> message is formatted as ``(4+1+2+2+n)[4] Rstat tag[2] n[2] (n-2)[2]
>> type[2] dev[4]...,'' where n is the value returned by convD2M."
>> It's appropriate to duplicate the size.  I think the Linux client
>> ignores it, but others implementations may complain.
> Thanks for the explanation!
> Yes, Linux implementation just throws it away - which was what confused
> me initially.
> Why not add a u16 to the beginning of 'struct p9_rstat'?
>
>>> - Update atime/mtime in p9_wstat, not really needed.
>> The underlying storage may handle this for you, I think 9p avoids
>> updating atime by default, at least in caching scenarios -- too much
>> unnecessary protocol traffic.
> My assumption was that the storage I read/write to will take care of it
> for me, and unless it bothers anyone in the future I'll assume it's
> doing a good job at it.
>
>>> - Pass usernames in p9_stat, not really needed and not really sure how p9 expects to handle them.
>> The username, group name issue is one of the principle reasons behind
>> the extended protocol operations (.u and .L) -- of course, if there
>> was a Plan 9 or Inferno guest they would be quite happy with the
>> usernames, but Linux (and other UNIX variants) will want the ids.  To
>> really keep things simple we could add a client option that would let
>> you pass the various ids as strings.  Although no doubt folks will
>> want the other extensions (symlinks, links, device nodes, etc.) before
>> long.  When we built the qemu server for .L, the team tried to keep
>> everything in a library, but there is some entanglement with the qemu
>> APIs -- it'd be nice if we could reuse that code here, maybe we need
>> an abstract glue layer so that the core code can be used by both the
>> kvm tool and qemu.  I'm copy the lead of that team on this message
>> just so he's aware how far you've come.
> I'd prefer using a tested lib which also implements .L over what we have
> now, assuming it's not tangled into qemu too hard.
>
Very interesting to see we have 9p in the KVM tool which we can use as 
root dev.
I think this is an excellent start.

We have been working on adding 9P2000.L support to both kernel and QEMU.
QEMU code is not tangled and it can be easily reused. Well easy to say. :)
The current mainline QEMU code is written in the state machine model we 
are working
on a series of patches to make use of coroutines which make the 
functions look
lot logical. You may look at the current dev branch here:
http://repo.or.cz/w/qemu/aliguori/jvrao.git/shortlog/refs/heads/9p-coroutine-bh

Thanks,
JV


>>           -eric
>

Re: [PATCH 2/2] kvm tools: Add virtio-9p

[Venkateswararao Jujjuri]

On 05/18/2011 02:05 AM, Sasha Levin wrote:
> On Tue, 2011-05-17 at 20:18 -0500, Eric Van Hensbergen wrote:
>> On Tue, May 17, 2011 at 3:27 PM, Sasha Levin<levinsasha928@gmail.com>  wrote:
>>> On Tue, 2011-05-17 at 22:08 +0300, Sasha Levin wrote:
>>>> 'kvm_9p' isn't created as a device under /dev, it's just a name used
>>>> internally by 9pnet_virtio (and located under sysfs).
>>>>
>>>> I couldn't figure out which params the kernel would expect to boot using
>>>> 9p over virtio (theres no device name to begin with).
>>>>
>>>> I've also couldn't find anything that suggested it's possible to boot
>>>> using virtio-9p as rootfs.
>>> Ignore that.
>>>
>>> Naming the virtio transport "/dev/root" and passing proper params to the
>>> kernel makes it work:
>>>
>>> [    1.844983] VFS: Mounted root (9p filesystem) on device 0:11.
>>>
>>> I'll make some changes to the virtio-9p patch to make it easier for the
>>> user to do that.

Any progress on this?  May I get more detailed instructions on how
you did this trick? Basically booting on 9P/VirtIO.

Thanks,
JV

>> This is really sweet.  Thanks for beating me to the punch of porting
>> the 9p support to kvm tools.
> Clear RFC and good source code to refer to within 9p modules made this
> easy (and fun) :)
>
>>> - Multiple virtio-9p devices.
>> This should be pretty straightforward.
> Yes, Most of the work here is within the kvm tool.
>
>>> - Ugly hack in virtio_p9_stat() (See desc in code).
>>>        /*
>>> +        * HACK: For some reason the p9 virtio transport reads a u16 and discards
>>> +        * it before reading the p9_rstat struct. I couldn't find a logical reason for
>>> +        * that, so we just add an extra u16 before the struct.
>>> +        */
>> This is part of the protocol spec (from
>> http://ericvh.github.com/9p-rfc/rfc9p2000.html#anchor32):
>> "To make the contents of a directory, such as returned by read(5),
>> easy to parse, each directory entry begins with a size field. For
>> consistency, the entries in Twstat and Rstat messages also contain
>> their size, which means the size appears twice. For example, the Rstat
>> message is formatted as ``(4+1+2+2+n)[4] Rstat tag[2] n[2] (n-2)[2]
>> type[2] dev[4]...,'' where n is the value returned by convD2M."
>> It's appropriate to duplicate the size.  I think the Linux client
>> ignores it, but others implementations may complain.
> Thanks for the explanation!
> Yes, Linux implementation just throws it away - which was what confused
> me initially.
> Why not add a u16 to the beginning of 'struct p9_rstat'?
>
>>> - Update atime/mtime in p9_wstat, not really needed.
>> The underlying storage may handle this for you, I think 9p avoids
>> updating atime by default, at least in caching scenarios -- too much
>> unnecessary protocol traffic.
> My assumption was that the storage I read/write to will take care of it
> for me, and unless it bothers anyone in the future I'll assume it's
> doing a good job at it.
>
>>> - Pass usernames in p9_stat, not really needed and not really sure how p9 expects to handle them.
>> The username, group name issue is one of the principle reasons behind
>> the extended protocol operations (.u and .L) -- of course, if there
>> was a Plan 9 or Inferno guest they would be quite happy with the
>> usernames, but Linux (and other UNIX variants) will want the ids.  To
>> really keep things simple we could add a client option that would let
>> you pass the various ids as strings.  Although no doubt folks will
>> want the other extensions (symlinks, links, device nodes, etc.) before
>> long.  When we built the qemu server for .L, the team tried to keep
>> everything in a library, but there is some entanglement with the qemu
>> APIs -- it'd be nice if we could reuse that code here, maybe we need
>> an abstract glue layer so that the core code can be used by both the
>> kvm tool and qemu.  I'm copy the lead of that team on this message
>> just so he's aware how far you've come.
> I'd prefer using a tested lib which also implements .L over what we have
> now, assuming it's not tangled into qemu too hard.
>
>
>>           -eric
>

Re: [PATCH 2/2] kvm tools: Add virtio-9p

[Sasha Levin]

On Thu, 2011-05-26 at 07:28 -0700, Venkateswararao Jujjuri wrote:
> Any progress on this?  May I get more detailed instructions on how
> you did this trick? Basically booting on 9P/VirtIO.
> 
> Thanks,
> JV
> 

Ofcourse. This change didn't go into tools/kvm/ since we only support
the legacy 9p2000 protocol at the moment, which means that even though
we can boot - it's quite unusable to work with.

The trick is pretty simple: You need to name your virtio transport
"/dev/root" (I think it's currently named "local" in qemu). Once it's
named this way, boot with the following kernel cmdline added:
"root=/dev/root rootflags=rw,trans=virtio,version=9p2000 rootfstype=9p
rw" (You should be able to change version to one of the 9p2000
extensions).

I've noticed that the transport *has* to be named "/dev/root", naming it
something else (and adjusting the "root=" parameter) doesn't seem to
work.

Also, if it's named "/dev/root" I couldn't mount it as a simple
filesystem from within a guest - not as root.

-- 

Sasha.

Re: [PATCH 2/2] kvm tools: Add virtio-9p

[Venkateswararao Jujjuri]

On 05/26/2011 07:36 AM, Sasha Levin wrote:
> On Thu, 2011-05-26 at 07:28 -0700, Venkateswararao Jujjuri wrote:
>> Any progress on this?  May I get more detailed instructions on how
>> you did this trick? Basically booting on 9P/VirtIO.
>>
>> Thanks,
>> JV
>>
> Ofcourse. This change didn't go into tools/kvm/ since we only support
> the legacy 9p2000 protocol at the moment, which means that even though
> we can boot - it's quite unusable to work with.
>
> The trick is pretty simple: You need to name your virtio transport
> "/dev/root" (I think it's currently named "local" in qemu). Once it's
> named this way, boot with the following kernel cmdline added:
> "root=/dev/root rootflags=rw,trans=virtio,version=9p2000 rootfstype=9p
> rw" (You should be able to change version to one of the 9p2000
> extensions).
Ah I guess you are making use of rootfstype.
So in this setup basically the virtio transport you create
is /dev/root instead of "kvm_9p" correct?
Also your dir will be / ?

i.e Start KVM with '--virtio-9p /'. ?
> I've noticed that the transport *has* to be named "/dev/root", naming it
> something else (and adjusting the "root=" parameter) doesn't seem to
> work.
>
> Also, if it's named "/dev/root" I couldn't mount it as a simple
> filesystem from within a guest - not as root.
>

Re: [PATCH 2/2] kvm tools: Add virtio-9p

[Sasha Levin]

On Thu, 2011-05-26 at 08:22 -0700, Venkateswararao Jujjuri wrote:
> On 05/26/2011 07:36 AM, Sasha Levin wrote:
> > On Thu, 2011-05-26 at 07:28 -0700, Venkateswararao Jujjuri wrote:
> >> Any progress on this?  May I get more detailed instructions on how
> >> you did this trick? Basically booting on 9P/VirtIO.
> >>
> >> Thanks,
> >> JV
> >>
> > Ofcourse. This change didn't go into tools/kvm/ since we only support
> > the legacy 9p2000 protocol at the moment, which means that even though
> > we can boot - it's quite unusable to work with.
> >
> > The trick is pretty simple: You need to name your virtio transport
> > "/dev/root" (I think it's currently named "local" in qemu). Once it's
> > named this way, boot with the following kernel cmdline added:
> > "root=/dev/root rootflags=rw,trans=virtio,version=9p2000 rootfstype=9p
> > rw" (You should be able to change version to one of the 9p2000
> > extensions).
> Ah I guess you are making use of rootfstype.
> So in this setup basically the virtio transport you create
> is /dev/root instead of "kvm_9p" correct?

Yes, exactly.

> Also your dir will be / ?
> 
> i.e Start KVM with '--virtio-9p /'. ?

It can be '/', but I'd suggest against trying to boot your hosts root
device within a guest (unless in RO mode maybe).

I've mounted a disk image to some directory on the host and booted that
directory for testing.

> > I've noticed that the transport *has* to be named "/dev/root", naming it
> > something else (and adjusting the "root=" parameter) doesn't seem to
> > work.
> >
> > Also, if it's named "/dev/root" I couldn't mount it as a simple
> > filesystem from within a guest - not as root.
> >
> 

-- 

Sasha.