Nothing calls it, and the existing virtio transport doesn't implement it. No functional change intended. MFC after: 1 week
No functional change intended. MFC after: 1 week
Allocating large buffers with M_ZERO adds unnecessary overhead since the data is immediately overwritten. This change embeds the tc and rc p9_buffer structs directly into p9_req_t so we only zero the small metadata headers. The actual data payload is allocated with M_NOWAIT. Embedding the metadata headers by value also allows the p9fs_buf_zone UMA items to be sized exactly to P9FS_MTU, ensuring they are nicely aligned. This also adds proper error handling to p9_get_request() to handle UMA allocation failures. Reviewed by: markj MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D56495
Previously, the UMA zones required for 9P requests (p9fs_buf_zone, p9fs_req_zone, etc.) were initialized and destroyed in the virtio_p9fs transport module. This caused issues when unloading the core p9fs module. This change moves p9_init_zones() and p9_destroy_zones() into p9fs_init() and p9fs_uninit() inside p9fs_vfsops.c so that they are correctly bound to the VFS filesystem module lifecycle via vfs_modevent, aligning p9fs with standard FreeBSD VFS semantics. Found while fixing https://github.com/CTSRD-CHERI/cheribsd/issues/2617. Reviewed by: kib MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D56492
The virtio_p9fs module event handler can be invoked multiple times. Previously, this caused p9_init_zones() and p9_register_trans() to be executed multiple times, leaking UMA zones and corrupting the transport list. During module unload, p9_destroy_zones() was also called multiple times on the same zone pointers, triggering a duplicate free kernel panic in uma_zdestroy(). This patch introduces a static reference counter in vt9p_modevent() to ensure the zones and transports are only initialized and destroyed exactly once, aligning with the approach used by other virtio drivers like vtnet. Reviewed by: kib, markj MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D56497
This allows us to also use the common VIRTIO_SIMPLE_PROBE and to have devmatch load the driver when detected. Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D54684
Some implementations of the virtio 9p transport are implemented on virtio_mmio, e.g. the Arm FVP. Use the correct macro so the driver attaches when this is the case. Reviewed by: markj Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D49600
Remove an always-false check for whether the request has already completed before sleeping. Even if the request is complete, the response tag is updated while holding the channel lock, which is also held here. No functional change intended. Sponsored by: Klara, Inc.
Otherwise we can end up with a lost interrupt, causing lost request completion wakeups and hangs in the filesystem layer. Continue processing until we enable interrupts and then observe an empty queue, like other virtio drivers do. Sponsored by: Klara, Inc.
If, when submitting a request, the virtqueue is full, we sleep until an interrupt has fired, then restart the request. However, while sleeping the channel lock is dropped, and in the meantime another thread may have reset the per-channel SG list, so upon retrying we'd (re)submit whatever happened to be left over in the previous request. Fix the problem by rebuilding the SG list after sleeping. Sponsored by: Klara, Inc.