NetBSD Problem Report #59165

From www@netbsd.org  Sun Mar  9 22:46:05 2025
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id D80CC1A9239
	for <gnats-bugs@gnats.NetBSD.org>; Sun,  9 Mar 2025 22:46:04 +0000 (UTC)
Message-Id: <20250309224603.CDFF71A923C@mollari.NetBSD.org>
Date: Sun,  9 Mar 2025 22:46:03 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: vio9p(4): expose tag through sysctl or device properties
X-Send-Pr-Version: www-1.0

>Number:         59165
>Category:       kern
>Synopsis:       vio9p(4): expose tag through sysctl or device properties
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          pending-pullups
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sun Mar 09 22:50:00 +0000 2025
>Closed-Date:    
>Last-Modified:  Thu May 15 17:55:01 +0000 2025
>Originator:     Taylor R Campbell
>Release:        current, 10, 9, ...
>Organization:
The Net9P Mountation
>Environment:
>Description:
In virtio-9p, the host passes a tag identifying each possible 9p mount point to the guest.  The mount tag is an arbitrary(?) string configured in the host (e.g., qemu -device virtio-9p-pci,mount_tag=FOO,...).

Currently, NetBSD only prints it to dmesg:

[     1.049667] vio9p0: tagged as FOO

It would be nice if this were exposed to userland via sysctl, device properties, or something, so that, e.g., a devpubd(8) hook could automatically create a symlink for it.
>How-To-Repeat:
try to juggle a collection of /dev/vio9pN mount points in the guest and host VM configuration
>Fix:
Yes, please!

>Release-Note:

>Audit-Trail:
From: Ryota Ozaki <ozaki-r@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/59165: vio9p(4): expose tag through sysctl or device properties
Date: Tue, 11 Mar 2025 12:30:58 +0900

 On Mon, Mar 10, 2025 at 7:50=E2=80=AFAM <campbell+netbsd@mumble.net> wrote:
 >
 > >Number:         59165
 > >Category:       kern
 > >Synopsis:       vio9p(4): expose tag through sysctl or device properties
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    kern-bug-people
 > >State:          open
 > >Class:          change-request
 > >Submitter-Id:   net
 > >Arrival-Date:   Sun Mar 09 22:50:00 +0000 2025
 > >Originator:     Taylor R Campbell
 > >Release:        current, 10, 9, ...
 > >Organization:
 > The Net9P Mountation
 > >Environment:
 > >Description:
 > In virtio-9p, the host passes a tag identifying each possible 9p mount po=
 int to the guest.  The mount tag is an arbitrary(?) string configured in th=
 e host (e.g., qemu -device virtio-9p-pci,mount_tag=3DFOO,...).
 >
 > Currently, NetBSD only prints it to dmesg:
 >
 > [     1.049667] vio9p0: tagged as FOO
 >
 > It would be nice if this were exposed to userland via sysctl, device prop=
 erties, or something, so that, e.g., a devpubd(8) hook could automatically =
 create a symlink for it.
 > >How-To-Repeat:
 > try to juggle a collection of /dev/vio9pN mount points in the guest and h=
 ost VM configuration
 > >Fix:
 > Yes, please!
 >

 I have a patch for systctl:
 https://www.netbsd.org/~ozaki-r/vio9p-tag-sysctl.patch
 Does it satisfy the demand?

   ozaki-r

From: Christoph Badura <bad@bsd.de>
To: gnats-bugs@netbsd.org
Cc: Ryota Ozaki <ozaki-r@netbsd.org>
Subject: Re: kern/59165: vio9p(4): expose tag through sysctl or device
 properties
Date: Tue, 11 Mar 2025 12:52:57 +0100

 On Tue, Mar 11, 2025 at 12:30:58PM +0900, Ryota Ozaki wrote:
 > I have a patch for systctl:
 > https://www.netbsd.org/~ozaki-r/vio9p-tag-sysctl.patch
 > Does it satisfy the demand?

 Thanks for working on this.  This could be very useful.

 If you attach multiple virtio-9p file systems to the VM, does your patch
 create hw.vio9p0.tag, hw.vio9p1.tag etc.?

 --chris

From: Ryota Ozaki <ozaki-r@netbsd.org>
To: Christoph Badura <bad@bsd.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/59165: vio9p(4): expose tag through sysctl or device properties
Date: Mon, 17 Mar 2025 17:33:44 +0900

 On Tue, Mar 11, 2025 at 8:53=E2=80=AFPM Christoph Badura <bad@bsd.de> wrote=
 :
 >
 > On Tue, Mar 11, 2025 at 12:30:58PM +0900, Ryota Ozaki wrote:
 > > I have a patch for systctl:
 > > https://www.netbsd.org/~ozaki-r/vio9p-tag-sysctl.patch
 > > Does it satisfy the demand?
 >
 > Thanks for working on this.  This could be very useful.
 >
 > If you attach multiple virtio-9p file systems to the VM, does your patch
 > create hw.vio9p0.tag, hw.vio9p1.tag etc.?

 Thank you for pointing this out. It assumed there was just one vio9p.
 I've put a fixed version:
 https://www.netbsd.org/~ozaki-r/vio9p-tag-sysctl.v2.patch

 Thanks,
   ozaki-r

From: Christoph Badura <bad@bsd.de>
To: gnats-bugs@netbsd.org
Cc: Ryota Ozaki <ozaki-r@netbsd.org>
Subject: Re: kern/59165: vio9p(4): expose tag through sysctl or device
 properties
Date: Tue, 18 Mar 2025 00:27:00 +0100

 On Mon, Mar 17, 2025 at 05:33:44PM +0900, Ryota Ozaki wrote:
 > On Tue, Mar 11, 2025 at 8:53 PM Christoph Badura <bad@bsd.de> wrote:
 > > If you attach multiple virtio-9p file systems to the VM, does your patch
 > > create hw.vio9p0.tag, hw.vio9p1.tag etc.?
 > Thank you for pointing this out. It assumed there was just one vio9p.

 I've been using at least two since last summer. :-)

 > I've put a fixed version:
 > https://www.netbsd.org/~ozaki-r/vio9p-tag-sysctl.v2.patch

 I guess the change from the previsous version is the use of
 device_xname(self) in:
 +	    device_xname(self), SYSCTL_DESCR("VirtIO 9p status"),

 That all looks fine to me.

 There is one more thing to think about: discoverability.
 How do we find out which hw.vio9pN sysctl nodes exist?

 Of course, we can do "sysctl hw | grep \^hw.vio9p" and process that.
 But that seems not right to me.
 We should have something like hw.disknames for vio9p.
 Maybe hw.vio9p.instances with a list of the instance names as strings?

 That shouldn't prevent you from committing your change

 Actually, I wish used a better MIB design in sysctl.
 Like:
   hw.vio9p.instances = vio9p0 vio9p1
   hw.vio9p.vio9p0.tag = tag1
   hw.vio9p.vio9p1.tag = tag2

 And likewise:
   hw.vm.wm0.*
   hw.vm.wm1.*
 etc.

 And a way for sysctl to just enumerate the immediate children of a node
 Like:
   $ sysctl --enumerate-children hw.wm
   hw.wm.wm0
   hw.wm.wm1
   $

 But we don't have that.  We could make a start with the hw.vio9p sub-MIB,
 though.

 But perhaps this should be discussed on tech-kern.

 --chris

From: Ryota Ozaki <ozaki-r@netbsd.org>
To: Christoph Badura <bad@bsd.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/59165: vio9p(4): expose tag through sysctl or device properties
Date: Tue, 25 Mar 2025 16:46:28 +0900

 I'm sorry for late reply...

 On Tue, Mar 18, 2025 at 8:27=E2=80=AFAM Christoph Badura <bad@bsd.de> wrote=
 :
 >
 > On Mon, Mar 17, 2025 at 05:33:44PM +0900, Ryota Ozaki wrote:
 > > On Tue, Mar 11, 2025 at 8:53=E2=80=AFPM Christoph Badura <bad@bsd.de> w=
 rote:
 > > > If you attach multiple virtio-9p file systems to the VM, does your pa=
 tch
 > > > create hw.vio9p0.tag, hw.vio9p1.tag etc.?
 > > Thank you for pointing this out. It assumed there was just one vio9p.
 >
 > I've been using at least two since last summer. :-)
 >
 > > I've put a fixed version:
 > > https://www.netbsd.org/~ozaki-r/vio9p-tag-sysctl.v2.patch
 >
 > I guess the change from the previsous version is the use of
 > device_xname(self) in:
 > +           device_xname(self), SYSCTL_DESCR("VirtIO 9p status"),
 >
 > That all looks fine to me.

 Thanks.

 >
 > There is one more thing to think about: discoverability.
 > How do we find out which hw.vio9pN sysctl nodes exist?
 >
 > Of course, we can do "sysctl hw | grep \^hw.vio9p" and process that.
 > But that seems not right to me.
 > We should have something like hw.disknames for vio9p.
 > Maybe hw.vio9p.instances with a list of the instance names as strings?
 >
 > That shouldn't prevent you from committing your change
 >
 > Actually, I wish used a better MIB design in sysctl.
 > Like:
 >   hw.vio9p.instances =3D vio9p0 vio9p1
 >   hw.vio9p.vio9p0.tag =3D tag1
 >   hw.vio9p.vio9p1.tag =3D tag2
 >
 > And likewise:
 >   hw.vm.wm0.*
 >   hw.vm.wm1.*
 > etc.
 >
 > And a way for sysctl to just enumerate the immediate children of a node
 > Like:
 >   $ sysctl --enumerate-children hw.wm
 >   hw.wm.wm0
 >   hw.wm.wm1
 >   $

 That reminds me of a RESTful API that requires listing up available endpoin=
 ts.
 I agree with the demand for discoverability, but in this case (sysctl
 MIBs) I don't
 desire it so much because, as you said, we can know the existing of sysctl =
 MIBs
 by using grep, etc. The proposed MIB design may help to make scripts simple=
 ,
 but I'm not sure if it's essential for everyone.

 >
 > But we don't have that.  We could make a start with the hw.vio9p sub-MIB,
 > though.
 >
 > But perhaps this should be discussed on tech-kern.

 I agree.

   ozaki-r

From: Christoph Badura <bad@bsd.de>
To: Ryota Ozaki <ozaki-r@netbsd.org>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/59165: vio9p(4): expose tag through sysctl or device
 properties
Date: Wed, 9 Apr 2025 19:38:42 +0200

 Darn, I wanted to reply earlier.

 On Tue, Mar 25, 2025 at 04:46:28PM +0900, Ryota Ozaki wrote:
 > That reminds me of a RESTful API that requires listing up available endpoints.

 I was reminded of SNMP.

 > I agree with the demand for discoverability, but in this case (sysctl
 > MIBs) I don't
 > desire it so much because, as you said, we can know the existing of sysctl MIBs
 > by using grep, etc. The proposed MIB design may help to make scripts simple,
 > but I'm not sure if it's essential for everyone.

 That's fine for scripts that run infrequently.  But it doesn't really work
 for stuff like systat or node_exporter which would query the MIB
 frequently.

 But we can address that later if the need arrives.

 --chris

From: Ryota Ozaki <ozaki-r@netbsd.org>
To: Christoph Badura <bad@bsd.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/59165: vio9p(4): expose tag through sysctl or device properties
Date: Thu, 17 Apr 2025 12:40:58 +0900

 On Thu, Apr 10, 2025 at 2:38=E2=80=AFAM Christoph Badura <bad@bsd.de> wrote=
 :
 >
 > Darn, I wanted to reply earlier.
 >
 > On Tue, Mar 25, 2025 at 04:46:28PM +0900, Ryota Ozaki wrote:
 > > That reminds me of a RESTful API that requires listing up available end=
 points.
 >
 > I was reminded of SNMP.
 >
 > > I agree with the demand for discoverability, but in this case (sysctl
 > > MIBs) I don't
 > > desire it so much because, as you said, we can know the existing of sys=
 ctl MIBs
 > > by using grep, etc. The proposed MIB design may help to make scripts si=
 mple,
 > > but I'm not sure if it's essential for everyone.
 >
 > That's fine for scripts that run infrequently.  But it doesn't really wor=
 k
 > for stuff like systat or node_exporter which would query the MIB
 > frequently.
 >
 > But we can address that later if the need arrives.

 Okay, I've prepared another patch that adds intermediate node, hw.vio9p,
 so I think it allows us to do further work on it:
   https://www.netbsd.org/~ozaki-r/vio9p-tag-sysctl.v3.patch

 BTW, with the new patch, sysctl hw.vio9p iterates available nodes of
 vio9p devices:
   kvm# sysctl hw.vio9p
   hw.vio9p.vio9p0.tag =3D test
   hw.vio9p.vio9p1.tag =3D test2

 Does this behavior just satisfy your demand?

   ozaki-r

From: Christoph Badura <bad@bsd.de>
To: Ryota Ozaki <ozaki-r@netbsd.org>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/59165: vio9p(4): expose tag through sysctl or device
 properties
Date: Thu, 17 Apr 2025 15:55:57 +0200

 On Thu, Apr 17, 2025 at 12:40:58PM +0900, Ryota Ozaki wrote:
 > Okay, I've prepared another patch that adds intermediate node, hw.vio9p,
 > so I think it allows us to do further work on it:
 >   https://www.netbsd.org/~ozaki-r/vio9p-tag-sysctl.v3.patch
 > 
 > BTW, with the new patch, sysctl hw.vio9p iterates available nodes of
 > vio9p devices:
 >   kvm# sysctl hw.vio9p
 >   hw.vio9p.vio9p0.tag = test
 >   hw.vio9p.vio9p1.tag = test2

 Wow! Thank you!  I really didn't expect that you would do this.  Thanks
 again!

 > Does this behavior just satisfy your demand?

 I wouldn't call it a demand.  More a suggestion and what I would prefer.

 --chris

From: "Ryota Ozaki" <ozaki-r@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/59165 CVS commit: src/sys/dev/pci
Date: Tue, 22 Apr 2025 05:56:25 +0000

 Module Name:	src
 Committed By:	ozaki-r
 Date:		Tue Apr 22 05:56:25 UTC 2025

 Modified Files:
 	src/sys/dev/pci: vio9p.c

 Log Message:
 vio9p: export tag via sysctl

 With this change, we can see tags of virtio-9p devices via sysctl:
   # sysctl hw.vio9p
   hw.vio9p.vio9p0.tag = test
   hw.vio9p.vio9p1.tag = test2

 PR kern/59165


 To generate a diff of this commit:
 cvs rdiff -u -r1.11 -r1.12 src/sys/dev/pci/vio9p.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Thu, 24 Apr 2025 12:24:43 +0000
State-Changed-Why:
Thanks!  I will try this out when I have a chance.  Might be worth
pullup-10 too.


State-Changed-From-To: needs-pullups->pending-pullups
State-Changed-By: ozaki-r@NetBSD.org
State-Changed-When: Mon, 12 May 2025 01:56:10 +0000
State-Changed-Why:
pullup-10 and pullup-9 done


From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/59165 CVS commit: [netbsd-10] src/sys/dev/pci
Date: Thu, 15 May 2025 17:53:24 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Thu May 15 17:53:24 UTC 2025

 Modified Files:
 	src/sys/dev/pci [netbsd-10]: vio9p.c

 Log Message:
 Pull up following revision(s) (requested by ozaki-r in ticket #1115):

 	sys/dev/pci/vio9p.c: revision 1.12

 vio9p: export tag via sysctl

 With this change, we can see tags of virtio-9p devices via sysctl:
   # sysctl hw.vio9p
   hw.vio9p.vio9p0.tag = test
   hw.vio9p.vio9p1.tag = test2

 PR kern/59165


 To generate a diff of this commit:
 cvs rdiff -u -r1.9.4.1 -r1.9.4.2 src/sys/dev/pci/vio9p.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

Home	PR Database Search