From mboxrd@z Thu Jan 1 00:00:00 1970 From: Venkateswararao Jujjuri Subject: Re: [PATCH 2/2] kvm tools: Add virtio-9p Date: Thu, 26 May 2011 07:28:40 -0700 Message-ID: <4DDE6398.107@linux.vnet.ibm.com> References: <1305657337-2584-1-git-send-email-levinsasha928@gmail.com> <1305657337-2584-2-git-send-email-levinsasha928@gmail.com> <20110517184023.GC16689@elte.hu> <1305659307.12150.37.camel@sasha> <1305664052.12150.43.camel@sasha> <1305709505.12150.71.camel@sasha> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Eric Van Hensbergen , Ingo Molnar , penberg@kernel.org, asias.hejun@gmail.com, prasadjoshi124@gmail.com, gorcunov@gmail.com, kvm@vger.kernel.org To: Sasha Levin Return-path: Received: from e32.co.us.ibm.com ([32.97.110.150]:47657 "EHLO e32.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757993Ab1EZO24 (ORCPT ); Thu, 26 May 2011 10:28:56 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4QEHRhS008427 for ; Thu, 26 May 2011 08:17:28 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p4QESt6Q131406 for ; Thu, 26 May 2011 08:28:55 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4Q8SFeR001123 for ; Thu, 26 May 2011 02:28:16 -0600 In-Reply-To: <1305709505.12150.71.camel@sasha> Sender: kvm-owner@vger.kernel.org List-ID: 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 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 >