I. PROJECT STATUS The project compiles and builds. The backend initialization works. The front end works partway through initialization. It dies in probe. This is because I initialized the mount path in the backend using the xenstore backend path, and tried to access it in the frontend with its path. Currently this path is hardcoded in the init code in xen_9pif.c. As I wrote in my commit message, this should be done in initialization. Ideally, to handle multiple mounts, the xenstore path should have a "mount directory" that contains all the file system mount paths. In addition, all of the front and backend code to manage the ring and the one entry grant table, as well as transferring data to and from the shared page has been tested and works. Most of the code for the entire project has been written. What I was going to do next (in this order) was: 1. Test: a. That the data transferred accurately. b. That the organization of the data being transferred is as I understand it. 2. Add and test transferring > 1 page of data. If 3b is AIUI, this is trivial. 3. Restore some of the configuration dependencies in the makefiles in qemu, and set them in the configure file. (See notes below) 4. Fix the white space in the different files. II. APPROACH I re-used a fair amount of virtio 9p code to produce the above. In this respect, the front-end required more code, but less modification to existing code. II. A. Front-end When I began, I assumed the code should eventually reside in net/9p. Only one file in this directory trans_virtio.c contains code that is virtio specific. The files client.c and mod.c, while technically part of virtio, could be used as is, and my code calls functions in these files. What I realized, in writing the backend, is that virtio provided the code that takes the initial client request, massages it, and "unmarshals" these requests in the backend. Client.c and mod.c, do this massaging in the front-end. The format of the data that client.c sends in a request is easily moved to a scatter-gather list. p9_front_driver.c contains all the functions specified in the xenbus_driver struct. The module initialization registers the front end with xenbus, and calls the 9p initialization code (in trans_xen9p.c) to register the 9p transport. The functions in trans_xen9p.c mimic their counterparts in trans_virtio.c, in that they provide the same functionality. They are the interface between the functions in client.c and the xen protocol. They receive requests from the client and call functions in p9_front.c to issue the request. The function in trans_xen9p.c, that handles these requests, is specified in the 9p initialization code. p9_front.c contains the code that talks to the back end. It contains the p9_connect function, which is invoked when the front and back-end are connected. It also manages the ring, and the grant table (which, at present has only one entry), receives requests from trans_xen9p.c, transfers the data into a shared page, and issues the request to the backend. When it receives a response, it passes the response information to req_done (in trans_xen9p.c), which processes it, and calls the client callback function. FYI - in linux/fs/fsdev there is the core of the 9p client code. I did not touch this code. II. B. Backend This was more complicated so I'll break it down into Background and What I did. Background: The virtio 9p backend code is composed of many files: virtio-9p.c contains most of the code to interpret the request from the client, and a few virtio-specific functions. virtio-9p-xattr.c and virtio-9p-xattr-user.c handle extended attribute requests. These files reside in qemu/hw/9pfs. virtio-9p-co*.c contain co-routines for all the functions in virtio-9p.c and virtio-xattr.c. virtio-9p-proxy.c, virtio-9p-synth.c, virtio-9p-local.c implement the various file systems that virtio supports. virtio-9p-device.c contains an implementation of the qemu object model for 9p. What I Did: I broke virtio-9p.c into two files: virtio-9p.c and v9fs_server.c. virtio-9p.c now contains three functions: complete_pdu, handle_9p_output, and a "constructor", virtio_9p_set_fd_limit. I created a "wrapper"header file for virtio-9p.h, v9fs_server.h. This wrapper creates a container for the V9fsState struct, V9GenericFsState, that contains a pointer to xen-specific data, and a pointer to a complete function, that can replace complete_pdu. There are other function pointers that I commented out, because they turned out not to be necessary. v9pfs_server.h also defines GENERIC_9P_SERVER. In virtio-9p.h, if GENERIC_9P_SERVER is defined, complete_pdu is defined to translate to the complete function in V9GenericFsState; if GENERIC_9P_SERVER is not defined, complete_pdu is simply declared. This is the only ifdef I added. I wrote a new file xen-9p.c that contains a complete_pdu function, xen_complete_pdu, xen_pdu_handle, and set_fd_limit. pdu's are the data structures that are passed among all the functions that handle file requests. They contain the meta-data necessary to process, and keep track of the request. xen_pdu_handle takes a requests and creates a pdu for the existing functions to handle the request. xen_complete_pdu takes a completed request, frees memory and calls p9_send_response in xen_9pif.c to handle the response. The rest of xen_9pif.c contains the code that interacts directly with the xenbus and indirectly with the front-end. Much of it was modeled after xen_disk.c, and tested when I was just passing small amounts of data back and forth. The backend also contains files in qemu/fsdev that set up the QemuOptsList tables and massage the data. I added qemu-xen-fsdev-opts.c, that was patterned after qemu-fsdev-opts.c. I also modified qemu-fsdev.c to add debugging statements. I modified vl.c and qemu-options.def, in the qemu directory to match what was done for virtio. Some of this works, but not all of it. I also modified xen_backend.h and xen_pv_machine.c to recognize this new backend. This code works. I mentioned I modified the Makefiles, in qemu/hw/9pfs, qemu/fsdev, in qemu/hw, and in qemu, inappropriately. I did not learn until the end of my internship exactly how to manipulate the configure files. Therefore, I removed or changed configuration dependencies, rather than change the makefiles. This should be fixed. Some FIXME statements that I put in to remind myself what I needed to do, actually got done, but I didn't remove the comment. III. How to Build My Project My code now resides only on my github: lindajac. The front-end code is in lindajac/lindap9/p9/p9front. To build it, assemble the front end files (p9_front.c p9_front_driver.c trans_xen9p.c and p9.h) in a directory with the Makefile. Copy from linux/net/9p, the header file trans_common.h, to this directory. This obviously has to change, when the front end has a permanent home directory. Type make. This will give you the front-end module. My backend resides under the github: lindajac/qemu on the branch mychanges. Because so much time has passed since my internship, it would have been more work than I was willing to do for free, for me to sync my project with the current qemu. Therefore, this needs to be done. The files that need to be merged manually are qemu/vl.c and qemu/hw/9pfs/virtio-9p.c. Given this caveat, if you checkout this branch, it will build, and create a usable qemu. IV. How to 'Use' My Project Here are the steps I follow. These steps have to be followed to test or to run the Xen 9p system. 1. Create and pause a guest ( -p option ). 2. Run xenstore-ls and edit the file to see what the domain number of the guest is. 3. Change the xenstore entries per the statements in the shell script lindap9/p9/p9front/p9xsupdate.sh. The parameter to this script is the domain number of the guest. 4. Start qemu. The qemu line I have been using (in a shell script) is -xen-domid $1 -chardev socket,\ id=libxl-cmd,path=/var/run/xen/qmp-libxl-$1,server,nowait -no-shutdown\ -mon chardev=libxl-cmd,mode=control -chardev socket,id=libxenstat-cmd,\ path=/var/run/xen/qmp-libxenstat-$1,server,nowait -mon chardev=libxenstat-cmd,\ mode=control -nodefaults -xen-attach -name testg -vnc 127.0.0.1:0,to=99 -display none -machine xenpv -m 2048\ -xen9pfs local,security_model=passthrough,id=fsdev0,path=/mnt,mount_tag=P9Mount where the last line is specific to 9p; all the rest is copied from the qemu parameters I captured using a shell script, early in this project. $1 is the guest domain. 5. Unpause the guest. 6. xl console 7. enter password. 8. scp the .ko of the front end to the guest 9. To run the front-end you need to modprobe my .ko, as well as the kernel modules linux/net/9p and linux/fs/9p, but they do not need to be built specially, for things to work. That's it.