From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37843) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpIdc-0006ll-Rf for qemu-devel@nongnu.org; Fri, 05 Aug 2011 07:32:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QpIdY-0000vW-PF for qemu-devel@nongnu.org; Fri, 05 Aug 2011 07:32:24 -0400 Received: from e38.co.us.ibm.com ([32.97.110.159]:41519) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpIdY-0000uu-Jm for qemu-devel@nongnu.org; Fri, 05 Aug 2011 07:32:20 -0400 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p753tA2p030801 for ; Thu, 4 Aug 2011 21:55:10 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p75BWI4m140782 for ; Fri, 5 Aug 2011 05:32:18 -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 p755VoXY011280 for ; Thu, 4 Aug 2011 23:31:51 -0600 From: "Aneesh Kumar K.V" In-Reply-To: References: <1312452371-10375-1-git-send-email-harsh@linux.vnet.ibm.com> <1312452371-10375-3-git-send-email-harsh@linux.vnet.ibm.com> <87hb5x1kyw.fsf@skywalker.in.ibm.com> <87ei111j0j.fsf@skywalker.in.ibm.com> <87bow510el.fsf@skywalker.in.ibm.com> <878vr81hu8.fsf@skywalker.in.ibm.com> Date: Fri, 05 Aug 2011 17:02:11 +0530 Message-ID: <8762mc14ck.fsf@skywalker.in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 2/2] i_generation / st_gen support for handle based fs driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Harsh Prateek Bora , qemu-devel@nongnu.org, Avi Kivity On Fri, 5 Aug 2011 10:24:42 +0100, Stefan Hajnoczi wro= te: > On Fri, Aug 5, 2011 at 7:40 AM, Aneesh Kumar K.V > wrote: > > On Thu, 4 Aug 2011 22:57:34 +0100, Stefan Hajnoczi = wrote: > >> On Thu, Aug 4, 2011 at 7:45 PM, Aneesh Kumar K.V > >> wrote: > >> > On Thu, 4 Aug 2011 15:31:08 +0100, Stefan Hajnoczi wrote: > >> >> On Thu, Aug 4, 2011 at 1:03 PM, Aneesh Kumar K.V > >> >> wrote: > >> >> > On Thu, 4 Aug 2011 12:47:42 +0100, Stefan Hajnoczi wrote: > >> >> >> On Thu, Aug 4, 2011 at 12:20 PM, Aneesh Kumar K.V > >> >> >> wrote: > >> >> >> > On Thu, 4 Aug 2011 11:21:05 +0100, Stefan Hajnoczi wrote: > >> >> >> >> On Thu, Aug 4, 2011 at 11:06 AM, Harsh Prateek Bora > >> >> >> >> wrote: > >> >> >> >> > This patch provides support for st_gen for handle based fs = type server. > >> >> >> >> > Currently the support is provided for ext4, btrfs, reiserfs= and xfs. > >> >> >> >> > > >> >> >> >> > Signed-off-by: Harsh Prateek Bora > >> >> >> >> > --- > >> >> >> >> > =C2=A0hw/9pfs/virtio-9p-handle.c | =C2=A0 30 ++++++++++++++= ++++++++++++++++ > >> >> >> >> > =C2=A01 files changed, 30 insertions(+), 0 deletions(-) > >> >> >> >> > >> >> >> >> Does handle-based file I/O really need to duplicate all this = code? =C2=A0Is > >> >> >> >> it possible to use either regular open or handle-based open f= rom a > >> >> >> >> single local fs codebase? > >> >> >> > > >> >> >> > The only details common between handle based and local based g= etversion > >> >> >> > callback is the ioctl. Moving that into a helper may not reall= y help in > >> >> >> > this case ?. > >> >> >> > >> >> >> Aneesh, do you have a public virtfs tree that I can look at? =C2= =A0In > >> >> >> qemu.git we don't have virtio-9p-handle.c yet, so I can't give a= ny > >> >> >> specific feedback. > >> >> > > >> >> > http://repo.or.cz/w/qemu/v9fs.git for-upstream > >> >> > > >> >> > I should send the patchset to qemu list soon. Was waiting for the > >> >> > co-routine patches to go upstream. > >> >> > >> >> The handle code looks like a copy of the local backend minus securi= ty > >> >> models. =C2=A0It just needs to use handle syscalls instead of using= paths. > >> >> > >> >> If you treat the path as the "handle" and use regular openat(2), th= en > >> >> the handle code could do what the local backend does today. =C2=A0E= xcept > >> >> compared to the local backend it would not have security models and= be > >> >> a bit slower due to extra syscalls. > >> >> > >> >> Is the plan to add security models to the handle backend? =C2=A0If = so, then > >> >> handle and local will be equivalent and duplicate code. > >> >> > >> > > >> > handle require root user privileges to run. So security model with > >> > handle fs driver doesn't make sense. We added mapped security model = to > >> > avoid requiring user to run as root. > >> > >> Does it really require root or is a specific set of capabilities > >> enough? > > > > CAP_DAC_READ_SEARCH =C2=A0is needed. > > > >> > >> A feature that requires QEMU to run as root has really limited value. > >> Unprivileged users cannot use the feature, so ad-hoc QEMU users are > >> left behind. =C2=A0People don't want to deploy production guests as ro= ot, > >> may not be allowed to, or might find that their management tool > >> doesn't support that. =C2=A0So who will be able to use this feature? > >> > > > > One of the main issue that handle based backend fix is the complexity > > involved in handling renames, both on the guest and on the host. I am > > also not sure how effective it would be to run the qemu as non root user > > when exporting a directory with VirtFS. In the mapped security model the > > user credentials with which the files are created are stored in xattr > > and that mostly implies host cannot look at the files the same way. > > > > My understanding is passthrough security model (which require qemu to > > run as root) will be used if somebody wants to export a directory on the > > host to guest. In my case I use none security model, simply because i > > don't want new xattr on the file created and I am ok even the files > > get created on the host with the credentials on qemu. >=20 > With xattrs you have to mount the directory on the host in order to > see the same view as the guest. How will that help ? There is nothing on the host that maps those xattr to mode/ownership bits currently. We will have to do something similar to f= use to make that work ?. My understanding was passthrough will be preferred option. But i may be mistaken. -aneesh