From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-5.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no
	version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id D06FAC47082
	for <linux-kernel@archiver.kernel.org>; Tue,  8 Jun 2021 19:34:13 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id BE8BF610A1
	for <linux-kernel@archiver.kernel.org>; Tue,  8 Jun 2021 19:34:13 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S237747AbhFHTgE (ORCPT <rfc822;linux-kernel@archiver.kernel.org>);
        Tue, 8 Jun 2021 15:36:04 -0400
Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:51947 "EHLO
        us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S237560AbhFHT2T (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 8 Jun 2021 15:28:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
        s=mimecast20190719; t=1623180384;
        h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
         to:to:cc:cc:mime-version:mime-version:content-type:content-type:
         content-transfer-encoding:content-transfer-encoding:
         in-reply-to:in-reply-to:references:references;
        bh=LPDqsEBP/MDK1aKd0nqXwm2OMJM183ITXNbTcctz3N8=;
        b=L4dGllb5cWYWby6qsKnCXbkFMxJFYQQ+pctsoRjdNoeOEVnoYb2Nf88t9k5G/E9X7o6eHL
        pjNiMn0fHlXee4Py5txzwGEBwAbKGWphMeASpECYxRqU0coP39gurd+gb79tMMljT3VyD0
        JQ8vr72NXeXfQq8bC0EPND8UZrusJ20=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-71-5-T2Gw-wOvKmizB1GzmYSg-1; Tue, 08 Jun 2021 15:26:23 -0400
X-MC-Unique: 5-T2Gw-wOvKmizB1GzmYSg-1
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14])
        (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
        (No client certificate requested)
        by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C8872107ACCD;
        Tue,  8 Jun 2021 19:26:21 +0000 (UTC)
Received: from horse.redhat.com (ovpn-114-35.rdu2.redhat.com [10.10.114.35])
        by smtp.corp.redhat.com (Postfix) with ESMTP id 5C5315D9E3;
        Tue,  8 Jun 2021 19:26:18 +0000 (UTC)
Received: by horse.redhat.com (Postfix, from userid 10451)
        id E422222054F; Tue,  8 Jun 2021 15:26:17 -0400 (EDT)
Date:   Tue, 8 Jun 2021 15:26:17 -0400
From:   Vivek Goyal <vgoyal@redhat.com>
To:     "Harry G. Coin" <hgcoin@gmail.com>
Cc:     linux-fsdevel@vger.kernel.org, virtio-fs@redhat.com,
        linux kernel mailing list <linux-kernel@vger.kernel.org>,
        Miklos Szeredi <miklos@szeredi.hu>,
        Richard Weinberger <richard.weinberger@gmail.com>,
        Dominique Martinet <asmadeus@codewreck.org>,
        David Howells <dhowells@redhat.com>, viro@zeniv.linux.org.uk,
        v9fs-developer@lists.sourceforge.net
Subject: Re: [Virtio-fs] [PATCH] init/do_mounts.c: Add root="fstag:<tag>"
 syntax for root device
Message-ID: <20210608192617.GC504497@redhat.com>
References: <20210608153524.GB504497@redhat.com>
 <8929c252-3d99-8cdb-1c56-5fdb1fd29fc2@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8929c252-3d99-8cdb-1c56-5fdb1fd29fc2@gmail.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Jun 08, 2021 at 01:38:56PM -0500, Harry G. Coin wrote:
> On 6/8/21 10:35 AM, Vivek Goyal wrote:
> > We want to be able to mount virtiofs as rootfs and pass appropriate
> > kernel command line. Right now there does not seem to be a good way
> > to do that. If I specify "root=myfs rootfstype=virtiofs", system
> > panics.
> >
> > virtio-fs: tag </dev/root> not found
> > ..
> > ..
> > [ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]
> 
> Whatever the best direction forward might be for kernel patches
> regarding 'not block device as root', it would ease learning curves if
> 'the patterns that set config issue X' were the same across root 'not
> block device options' whether cephfs, nfs, 9p, virtiofs.

I think achieveing same pattern for all non-block options is pretty
hard. There are too many varieits, mtd, ubifs, nfs, cifs, and you
just mentioned cephfs.

It would be nice if somebody can achieve it. But that should not be
a blocker for this patch. Goal of this patch is to take care of virtiofs
and 9p. And any other filesystem which can work with this pattern.

I think ubi and mtd should be able to work with "root=fstag:<tag>"
as well. Something like "root=fstag:ubi:foo". And then ubi:foo
will should be passed to ubifs. I think only thing missing is
that current code assumes there is one filesystem passed in
rootfstype. If we want to try mounting device with multiple
filesystems then one can modify the code to call do_mount_root()
in a loop from a filesystem list.

Right now I did not need it, so I did not add it.

> All of them
> will have to handle the selinux xattr/issue, posix and flock issues,
> caching etc.

Filesystem specific flags will be passed by rootflags=.

> While by definition virtiofs has to exist only in a vm
> guest, the others could be baremetal or vm guest roots.  (How much 9p's
> other-than-guest transports are used I don't know).
> 
> FYI (though patching the kernel may be the best option)  there is a case
> that does not have those kernel panics for virtiofs-root and 9p root
> using stock fc34.  As 9p, the virtiofs method uses the initrd creation
> mechanisms provided by 'dracut' or 'initramfs' to provide the 'sysroot
> pivot glue'.
> 
> On the fc34 guest a successful 'direct kernel boot' today looks like:
> 
> kernel path: /vmsystems/fedora_generic/boot/vmlinuz
> 
> initrd path: /vmsystems/fedora_generic/boot/initrd.img
> 
> Kernel args: root=virtiofs:myfs rd.shell rd.fstab

Does it work with upstream dracut or you have modified dracut to
parse "root=virtiofs:myfs" option.

I think it probably is better that both kernel and dracut parse
and understand same "root=" format string and I will try to
avoid creating a "root=" option which dracut understands but
not kernel. Or try creating two different wasy to mount 
virtiofs using "root=" for kernel and dracut.

That's why I am first trying to get this new syntax in the kernel
and once it works, I want to follow up with dracut folks to
parse "root=fstag:<tag>" and be able to mount virtiofs/9p/foo
filesystem.

Thanks
Vivek

> 
> 
> The xml to pass through virtio-fs is:
> 
> <filesystem type="mount" accessmode="passthrough">
>   <driver type="virtiofs" queue="1024"/>
>   <binary xattr="on">
>     <lock posix="on" flock="on"/>
>   </binary>
>   <source dir="/vmsystems/fedora_generic"/>
>   <target dir="myfs"/>
> </filesystem>
> 
> The guest fstab is:
> 
> myfs / virtiofs defaults 0 0
> 
> HTH
> 
> Harry Coin
> 
> 
> 


From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Tue, 8 Jun 2021 15:26:17 -0400
From: Vivek Goyal <vgoyal@redhat.com>
Message-ID: <20210608192617.GC504497@redhat.com>
References: <20210608153524.GB504497@redhat.com>
	<8929c252-3d99-8cdb-1c56-5fdb1fd29fc2@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <8929c252-3d99-8cdb-1c56-5fdb1fd29fc2@gmail.com>
Subject: Re: [Virtio-fs] [PATCH] init/do_mounts.c: Add root="fstag:<tag>"
 syntax for root device
List-Id: Development discussions about virtio-fs <virtio-fs.redhat.com>
List-Unsubscribe: <https://listman.redhat.com/mailman/options/virtio-fs>,
	<mailto:virtio-fs-request@redhat.com?subject=unsubscribe>
List-Archive: <https://listman.redhat.com/archives/virtio-fs>
List-Post: <mailto:virtio-fs@redhat.com>
List-Help: <mailto:virtio-fs-request@redhat.com?subject=help>
List-Subscribe: <https://listman.redhat.com/mailman/listinfo/virtio-fs>,
	<mailto:virtio-fs-request@redhat.com?subject=subscribe>
To: "Harry G. Coin" <hgcoin@gmail.com>
Cc: David Howells <dhowells@redhat.com>, Miklos Szeredi <miklos@szeredi.hu>, Richard Weinberger <richard.weinberger@gmail.com>, Dominique Martinet <asmadeus@codewreck.org>, linux kernel mailing list <linux-kernel@vger.kernel.org>, virtio-fs@redhat.com, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, v9fs-developer@lists.sourceforge.net

On Tue, Jun 08, 2021 at 01:38:56PM -0500, Harry G. Coin wrote:
> On 6/8/21 10:35 AM, Vivek Goyal wrote:
> > We want to be able to mount virtiofs as rootfs and pass appropriate
> > kernel command line. Right now there does not seem to be a good way
> > to do that. If I specify "root=3Dmyfs rootfstype=3Dvirtiofs", system
> > panics.
> >
> > virtio-fs: tag </dev/root> not found
> > ..
> > ..
> > [ end Kernel panic - not syncing: VFS: Unable to mount root fs on unkno=
wn-block(0,0) ]
>=20
> Whatever the best direction forward might be for kernel patches
> regarding 'not block device as root', it would ease learning curves if
> 'the patterns that set config issue X' were the same across root 'not
> block device options' whether cephfs, nfs, 9p, virtiofs.

I think achieveing same pattern for all non-block options is pretty
hard. There are too many varieits, mtd, ubifs, nfs, cifs, and you
just mentioned cephfs.

It would be nice if somebody can achieve it. But that should not be
a blocker for this patch. Goal of this patch is to take care of virtiofs
and 9p. And any other filesystem which can work with this pattern.

I think ubi and mtd should be able to work with "root=3Dfstag:<tag>"
as well. Something like "root=3Dfstag:ubi:foo". And then ubi:foo
will should be passed to ubifs. I think only thing missing is
that current code assumes there is one filesystem passed in
rootfstype. If we want to try mounting device with multiple
filesystems then one can modify the code to call do_mount_root()
in a loop from a filesystem list.

Right now I did not need it, so I did not add it.

> All of them
> will have to handle the selinux xattr/issue, posix and flock issues,
> caching etc.

Filesystem specific flags will be passed by rootflags=3D.

> While by definition virtiofs has to exist only in a vm
> guest, the others could be baremetal or vm guest roots.=A0 (How much 9p's
> other-than-guest transports are used I don't know).
>=20
> FYI (though patching the kernel may be the best option)=A0 there is a case
> that does not have those kernel panics for virtiofs-root and 9p root
> using stock fc34.=A0 As 9p, the virtiofs method uses the initrd creation
> mechanisms provided by 'dracut' or 'initramfs' to provide the 'sysroot
> pivot glue'.
>=20
> On the fc34 guest a successful 'direct kernel boot' today looks like:
>=20
> kernel path: /vmsystems/fedora_generic/boot/vmlinuz
>=20
> initrd path: /vmsystems/fedora_generic/boot/initrd.img
>=20
> Kernel args: root=3Dvirtiofs:myfs rd.shell rd.fstab

Does it work with upstream dracut or you have modified dracut to
parse "root=3Dvirtiofs:myfs" option.

I think it probably is better that both kernel and dracut parse
and understand same "root=3D" format string and I will try to
avoid creating a "root=3D" option which dracut understands but
not kernel. Or try creating two different wasy to mount=20
virtiofs using "root=3D" for kernel and dracut.

That's why I am first trying to get this new syntax in the kernel
and once it works, I want to follow up with dracut folks to
parse "root=3Dfstag:<tag>" and be able to mount virtiofs/9p/foo
filesystem.

Thanks
Vivek

>=20
>=20
> The xml to pass through virtio-fs is:
>=20
> <filesystem type=3D"mount" accessmode=3D"passthrough">
> =A0 <driver type=3D"virtiofs" queue=3D"1024"/>
> =A0 <binary xattr=3D"on">
> =A0=A0=A0 <lock posix=3D"on" flock=3D"on"/>
> =A0 </binary>
> =A0 <source dir=3D"/vmsystems/fedora_generic"/>
> =A0 <target dir=3D"myfs"/>
> </filesystem>
>=20
> The guest fstab is:
>=20
> myfs / virtiofs defaults 0 0
>=20
> HTH
>=20
> Harry Coin
>=20
>=20
>=20