* [PATCH v3] net/9p: add vsock transport
@ 2026-07-09 16:17 skvarlamatus
2026-09-13 14:09 ` Dominique Martinet
0 siblings, 1 reply; 4+ messages in thread
From: skvarlamatus @ 2026-07-09 16:17 UTC (permalink / raw)
To: ericvh, lucho, asmadeus, linux_oss, stefanha, skvarlamatus
Cc: v9fs, linux-kernel, sgarzare
From: Matus Skvarla <skvarlamatus@gmail.com>
Add vsock as a transport option for 9P client connections. This
allows mounting 9P filesystems over VM sockets without requiring TCP/IP
networking or additional userspace tools.
The implementation extends trans_fd.c with vsock support, reusing the
existing socket infrastructure. A new p9_fd_create_vsock() function
handles vsock connection setup by parsing the CID from the mount source,
creating an AF_VSOCK socket, and connecting to the specified endpoint.
All other transport operations (close, request, cancel) use the shared
fd transport implementation.
The privport mount option is not currently implemented for vsock and
returns -EOPNOTSUPP if specified.
Add CONFIG_NET_9P_VSOCK option that conditionally compiles vsock support
into 9pnet_fd.ko. This follows the pattern where socket-based transports
(TCP, Unix, vsock) share trans_fd.c, while specialized hardware transports
(virtio, xen, rdma) have dedicated files.
Usage:
mount -t 9p -o trans=vsock[,port=<port>] <CID> /mnt/point
Signed-off-by: Matus Skvarla <skvarlamatus@gmail.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Acked-by: Stefano Garzarella <sgarzare@redhat.com>
---
Changes in v3:
- Add port= option to vsock mount example in documentation
- Drop unrelated typo fix in documentation
- Add TODO comment for vsock privport binding
- Clarify privport error message as "currently not implemented"
Link to v2: https://lore.kernel.org/v9fs/20260701155922.95502-1-skvarlamatus@gmail.com/
Changes in v2:
- Add depends on NET_9P_FD to Kconfig
- Use #include <uapi/linux/vm_sockets.h>
- Reject privport option with -EOPNOTSUPP
- Use fc->net_ns instead of current->nsproxy->net_ns
- Widen vsock port to u32 to match sockaddr_vm.svm_port
- Widen p9_fd_opts.port to u32 and port_str buffer accordingly (in p9_fd_create_tcp())
- Add vsock to Documentation/filesystems/9p.rst
Link to v1: https://lore.kernel.org/v9fs/20260527073447.86538-1-skvarlamatus@gmail.com/
---
Documentation/filesystems/9p.rst | 10 ++++
include/net/9p/client.h | 10 +++-
net/9p/Kconfig | 10 ++++
net/9p/trans_fd.c | 98 +++++++++++++++++++++++++++++++-
4 files changed, 124 insertions(+), 4 deletions(-)
diff --git a/Documentation/filesystems/9p.rst b/Documentation/filesystems/9p.rst
index 3f65db648db0..44b9e1b5eab7 100644
--- a/Documentation/filesystems/9p.rst
+++ b/Documentation/filesystems/9p.rst
@@ -50,6 +50,14 @@ mount points. Each 9P export is seen by the client as a virtio device with an
associated "mount_tag" property. Available mount tags can be
seen by reading /sys/bus/virtio/drivers/9pnet_virtio/virtio<n>/mount_tag files.
+For server accessible over vsock (VM sockets)::
+
+ mount -t 9p -o trans=vsock[,port=<port>] <CID> /mnt/9
+
+where CID is the vsock Context ID of the remote endpoint (2 for host from
+a guest VM, 3+ for guest VMs from the host). The port to connect to can be
+specified with the port option (default: 564).
+
USBG Usage
==========
@@ -117,6 +125,8 @@ Options
tcp specifying a normal TCP/IP connection
fd used passed file descriptors for connection
(see rfdno and wfdno)
+ vsock connect over VM sockets (vsock) using
+ CID as the mount source
virtio connect to the next virtio channel available
(from QEMU with trans_virtio module)
rdma connect to a specified RDMA channel
diff --git a/include/net/9p/client.h b/include/net/9p/client.h
index 55c6cb54bd25..c0eca56c1f5f 100644
--- a/include/net/9p/client.h
+++ b/include/net/9p/client.h
@@ -122,8 +122,12 @@ struct p9_client {
struct {
u16 port;
bool privport;
-
} tcp;
+#if IS_ENABLED(CONFIG_NET_9P_VSOCK)
+ struct {
+ u32 port;
+ } vsock;
+#endif
} trans_opts;
struct idr fids;
@@ -151,13 +155,13 @@ struct p9_client_opts {
* struct p9_fd_opts - per-transport options for fd transport
* @rfd: file descriptor for reading (trans=fd)
* @wfd: file descriptor for writing (trans=fd)
- * @port: port to connect to (trans=tcp)
+ * @port: port to connect to (trans=tcp, trans=vsock)
* @privport: port is privileged
*/
struct p9_fd_opts {
int rfd;
int wfd;
- u16 port;
+ u32 port;
bool privport;
};
diff --git a/net/9p/Kconfig b/net/9p/Kconfig
index 22f8c167845d..b0a6342e3475 100644
--- a/net/9p/Kconfig
+++ b/net/9p/Kconfig
@@ -32,6 +32,16 @@ config NET_9P_VIRTIO
This builds support for a transports between
guest partitions and a host partition.
+config NET_9P_VSOCK
+ depends on NET_9P_FD
+ depends on VSOCKETS
+ bool "9P VSOCK Transport"
+ help
+ This builds support for a transport for 9pfs over
+ virtual sockets (vsock). This is useful for communication
+ between virtual machines and their host without requiring
+ TCP/IP networking configuration or additional userspace software.
+
config NET_9P_XEN
depends on XEN
select XEN_XENBUS_FRONTEND
diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
index eb685b52aeb2..54aad5bb975a 100644
--- a/net/9p/trans_fd.c
+++ b/net/9p/trans_fd.c
@@ -28,6 +28,9 @@
#include <net/9p/9p.h>
#include <net/9p/client.h>
#include <net/9p/transport.h>
+#if IS_ENABLED(CONFIG_NET_9P_VSOCK)
+#include <uapi/linux/vm_sockets.h>
+#endif
#include <linux/syscalls.h> /* killme */
@@ -36,6 +39,9 @@
static struct p9_trans_module p9_tcp_trans;
static struct p9_trans_module p9_fd_trans;
+#if IS_ENABLED(CONFIG_NET_9P_VSOCK)
+static struct p9_trans_module p9_vsock_trans;
+#endif
enum {
Rworksched = 1, /* read work scheduled or running */
@@ -714,6 +720,12 @@ static int p9_fd_show_options(struct seq_file *m, struct p9_client *clnt)
if (clnt->trans_opts.fd.wfd != ~0)
seq_printf(m, ",wfd=%u", clnt->trans_opts.fd.wfd);
}
+#if IS_ENABLED(CONFIG_NET_9P_VSOCK)
+ else if (clnt->trans_mod == &p9_vsock_trans) {
+ if (clnt->trans_opts.vsock.port != P9_FD_PORT)
+ seq_printf(m, ",port=%u", clnt->trans_opts.vsock.port);
+ }
+#endif
return 0;
}
@@ -875,7 +887,7 @@ p9_fd_create_tcp(struct p9_client *client, struct fs_context *fc)
const char *addr = fc->source;
struct v9fs_context *ctx = fc->fs_private;
int err;
- char port_str[6];
+ char port_str[11];
struct socket *csocket;
struct sockaddr_storage stor = { 0 };
struct p9_fd_opts opts;
@@ -966,6 +978,67 @@ p9_fd_create_unix(struct p9_client *client, struct fs_context *fc)
return p9_socket_open(client, csocket);
}
+#if IS_ENABLED(CONFIG_NET_9P_VSOCK)
+static int
+p9_fd_create_vsock(struct p9_client *client, struct fs_context *fc)
+{
+ const char *addr = fc->source;
+ struct v9fs_context *ctx = fc->fs_private;
+ int err;
+ struct socket *csocket;
+ struct sockaddr_vm addr_vm = { 0 };
+ struct p9_fd_opts opts;
+ unsigned int cid;
+
+ /* opts are already parsed in context */
+ opts = ctx->fd_opts;
+
+ if (opts.privport) {
+ // TODO: implement vsock privileged port binding
+ pr_err("%s (%d): privport currently not implemented for vsock\n",
+ __func__, task_pid_nr(current));
+ return -EOPNOTSUPP;
+ }
+
+ if (!addr)
+ return -EINVAL;
+
+ err = kstrtouint(addr, 10, &cid);
+ if (err < 0) {
+ pr_err("%s (%d): invalid CID: %s\n",
+ __func__, task_pid_nr(current), addr);
+ return err;
+ }
+
+ csocket = NULL;
+
+ client->trans_opts.vsock.port = opts.port;
+ err = __sock_create(fc->net_ns, AF_VSOCK,
+ SOCK_STREAM, 0, &csocket, 1);
+ if (err) {
+ pr_err("%s (%d): problem creating socket\n",
+ __func__, task_pid_nr(current));
+ return err;
+ }
+
+ addr_vm.svm_family = AF_VSOCK;
+ addr_vm.svm_port = opts.port;
+ addr_vm.svm_cid = cid;
+
+ err = READ_ONCE(csocket->ops)->connect(csocket,
+ (struct sockaddr_unsized *)&addr_vm,
+ sizeof(addr_vm), 0);
+ if (err < 0) {
+ pr_err("%s (%d): problem connecting socket to %s:%u\n",
+ __func__, task_pid_nr(current), addr, opts.port);
+ sock_release(csocket);
+ return err;
+ }
+
+ return p9_socket_open(client, csocket);
+}
+#endif /* CONFIG_NET_9P_VSOCK */
+
static int
p9_fd_create(struct p9_client *client, struct fs_context *fc)
{
@@ -1036,6 +1109,23 @@ static struct p9_trans_module p9_fd_trans = {
};
MODULE_ALIAS_9P("fd");
+#if IS_ENABLED(CONFIG_NET_9P_VSOCK)
+static struct p9_trans_module p9_vsock_trans = {
+ .name = "vsock",
+ .maxsize = MAX_SOCK_BUF,
+ .def = false,
+ .supports_vmalloc = true,
+ .create = p9_fd_create_vsock,
+ .close = p9_fd_close,
+ .request = p9_fd_request,
+ .cancel = p9_fd_cancel,
+ .cancelled = p9_fd_cancelled,
+ .show_options = p9_fd_show_options,
+ .owner = THIS_MODULE,
+};
+MODULE_ALIAS_9P("vsock");
+#endif
+
/**
* p9_poll_workfn - poll worker thread
* @work: work queue
@@ -1073,6 +1163,9 @@ static int __init p9_trans_fd_init(void)
v9fs_register_trans(&p9_tcp_trans);
v9fs_register_trans(&p9_unix_trans);
v9fs_register_trans(&p9_fd_trans);
+#if IS_ENABLED(CONFIG_NET_9P_VSOCK)
+ v9fs_register_trans(&p9_vsock_trans);
+#endif
return 0;
}
@@ -1083,6 +1176,9 @@ static void __exit p9_trans_fd_exit(void)
v9fs_unregister_trans(&p9_tcp_trans);
v9fs_unregister_trans(&p9_unix_trans);
v9fs_unregister_trans(&p9_fd_trans);
+#if IS_ENABLED(CONFIG_NET_9P_VSOCK)
+ v9fs_unregister_trans(&p9_vsock_trans);
+#endif
}
module_init(p9_trans_fd_init);
--
2.47.1
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v3] net/9p: add vsock transport
2026-07-09 16:17 [PATCH v3] net/9p: add vsock transport skvarlamatus
@ 2026-09-13 14:09 ` Dominique Martinet
2026-09-14 17:51 ` skvarlamatus
0 siblings, 1 reply; 4+ messages in thread
From: Dominique Martinet @ 2026-09-13 14:09 UTC (permalink / raw)
To: skvarlamatus
Cc: ericvh, lucho, linux_oss, stefanha, v9fs, linux-kernel, sgarzare
skvarlamatus@gmail.com wrote on Thu, Jul 09, 2026 at 06:17:41PM +0200:
> From: Matus Skvarla <skvarlamatus@gmail.com>
>
> Add vsock as a transport option for 9P client connections. This
> allows mounting 9P filesystems over VM sockets without requiring TCP/IP
> networking or additional userspace tools.
>
> The implementation extends trans_fd.c with vsock support, reusing the
> existing socket infrastructure. A new p9_fd_create_vsock() function
> handles vsock connection setup by parsing the CID from the mount source,
> creating an AF_VSOCK socket, and connecting to the specified endpoint.
> All other transport operations (close, request, cancel) use the shared
> fd transport implementation.
>
> The privport mount option is not currently implemented for vsock and
> returns -EOPNOTSUPP if specified.
>
> Add CONFIG_NET_9P_VSOCK option that conditionally compiles vsock support
> into 9pnet_fd.ko. This follows the pattern where socket-based transports
> (TCP, Unix, vsock) share trans_fd.c, while specialized hardware transports
> (virtio, xen, rdma) have dedicated files.
>
> Usage:
> mount -t 9p -o trans=vsock[,port=<port>] <CID> /mnt/point
>
> Signed-off-by: Matus Skvarla <skvarlamatus@gmail.com>
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> Acked-by: Stefano Garzarella <sgarzare@redhat.com>
Thanks for the v3
I'm mostly happy with the code, but I have a few high level questions
before sending this to Linus (I'll probably take the patch for -next
next week anyway):
- I've looked at v1/v2 threads and I don't actually see any rationale
explained: what's the benefit of this over e.g. virito or xen
transports?
Do you have/use an hypervisor that cannot do virito 9p (or virtfs) but
has vsock or something like that?
- On a similar topic, do you have an actual server that works with
vsock?
I've seen I can test with diod+socat[1], but I expect to see a real user
ready if this is merged, not just "this can work"
[1] https://github.com/chaos/diod/issues/148
Thanks,
--
Dominique Martinet | Asmadeus
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v3] net/9p: add vsock transport
2026-09-13 14:09 ` Dominique Martinet
@ 2026-09-14 17:51 ` skvarlamatus
2026-09-14 23:44 ` Dominique Martinet
0 siblings, 1 reply; 4+ messages in thread
From: skvarlamatus @ 2026-09-14 17:51 UTC (permalink / raw)
To: asmadeus, skvarlamatus
Cc: ericvh, lucho, linux_oss, v9fs, linux-kernel, stefanha, sgarzare
On Sun, Sep 13, 2026 at 14:09 +0000, asmadeus@codewreck.org wrote:
> I've looked at v1/v2 threads and I don't actually see any rationale
> explained: what's the benefit of this over e.g. virito or xen
> transports?
> Do you have/use an hypervisor that cannot do virito 9p (or virtfs) but
> has vsock or something like that?
virtio-9p is only supported by Qemu/KVM. Vsock transport works on any hypervisor
with vsock support and allows using userspace 9P servers.
The motivation behind this patch is primarily driven by podman machine's
use-case, which is file sharing on Windows [1] [2].
The hypervisor there is Hyper-V/WSL, which supports vsock for host-guest
data transfers [3], but not virtio-9p or virtfs. Having vsock transport in the
driver would simplify the codebase and make the use-case more flexible.
> On a similar topic, do you have an actual server that works with vsock?
Podman implements its own 9P server in Go using the p9 library [4] with
vsock support via virtsock [5], but it runs as part of podman machine.
For standalone 9p servers, I only know of diod and example implementations
of various 9p server libraries (i.e. [6]), but none of them support vsock.
As far as I know, there is one 9p FUSE client with native vsock support
(my contribution) [7].
[1] https://github.com/podman-container-tools/podman/blob/main/cmd/podman/machine/server9p.go
[2] https://github.com/podman-container-tools/podman/blob/main/cmd/podman/machine/client9p.go
[3] https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/make-integration-service
[4] https://github.com/hugelgupf/p9
[5] https://github.com/linuxkit/virtsock
[6] https://github.com/hugelgupf/p9/blob/main/cmd/p9ufs/p9ufs.go
[7] https://github.com/ftrvxmtrx/9pfs
--
Matus
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v3] net/9p: add vsock transport
2026-09-14 17:51 ` skvarlamatus
@ 2026-09-14 23:44 ` Dominique Martinet
0 siblings, 0 replies; 4+ messages in thread
From: Dominique Martinet @ 2026-09-14 23:44 UTC (permalink / raw)
To: skvarlamatus
Cc: ericvh, lucho, linux_oss, v9fs, linux-kernel, stefanha, sgarzare
skvarlamatus@gmail.com wrote on Mon, Sep 14, 2026 at 07:51:56PM +0200:
>> Do you have/use an hypervisor that cannot do virito 9p (or virtfs) but
>> has vsock or something like that?
>
> virtio-9p is only supported by Qemu/KVM. Vsock transport works on any hypervisor
> with vsock support and allows using userspace 9P servers.
> The motivation behind this patch is primarily driven by podman machine's
> use-case, which is file sharing on Windows [1] [2].
> The hypervisor there is Hyper-V/WSL, which supports vsock for host-guest
> data transfers [3], but not virtio-9p or virtfs. Having vsock transport in the
> driver would simplify the codebase and make the use-case more flexible.
Okay, thank you for the explanation -- I'll add a blurb to the commit
message with your links for reference.
> > On a similar topic, do you have an actual server that works with vsock?
>
> Podman implements its own 9P server in Go using the p9 library [4] with
> vsock support via virtsock [5], but it runs as part of podman machine.
> For standalone 9p servers, I only know of diod and example implementations
> of various 9p server libraries (i.e. [6]), but none of them support vsock.
Right, diod has an open issue[1] for vsock but since there were no
obvious client available either it was never done.
I don't think it's difficult to do (probably more work to add the option
parsing than the actual vsock support), but for now I was able to verify
this works with diod + socat as described in the issue, so this can come
later if/when there is interest for other hypervisors.
[1] https://github.com/chaos/diod/issues/148
--
Dominique Martinet | Asmadeus
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-09-14 23:44 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-07-09 16:17 [PATCH v3] net/9p: add vsock transport skvarlamatus
2026-09-13 14:09 ` Dominique Martinet
2026-09-14 17:51 ` skvarlamatus
2026-09-14 23:44 ` Dominique Martinet
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®