Adding Eugenio and YongJi. On Wed, Dec 4, 2024 at 11:38 PM <t.ampelikiotis@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > From: Timos Ampelikiotis <t.ampelikiotis@xxxxxxxxxxxxxxxxxxxxxx> > > We would like to share with you an RFC for the Virtio-loopback > technology which we have been working on at Virtual Open Systems in > the context of the Automotive Grade Linux community (Software defined > Vehicles expert group) > > We previously presented this activity (see [1]) and now we come back > to you with latest development and updates. > > We believe that the technology is more mature today and we would like > to assess the community interest in the technology itself and in > merging the code. > > Below we provide a brief description of the technology, recent > updates and a short comparison with vDUSE that might be seen as a > similar technology. > > 1. Overview: > ------- > > Virtio-loopback is a hardware abstraction layer (HAL) designed for > non-virtualized environments based on virtio. The main objective is > to enable applications communication with vhost-user devices in a > non-virtualized environment. > > More in details, Virtio-loopback architecture consists of a new > transport (Virtio-loopback), a user-space application (Adapter) and > the vhost-user devices. > > The data path has been implemented using the "zero-copy" principle, This need more clarification, for example, how could we prevent malicious usersapce device from modifying kernel pages etc. Especially consider not all buffer occupy full pages. Actually, after chatting with Yong Ji, I've played with a zerocopy POC for VDUSE, but it tries to do zerocopy only for page aligned buffer: https://github.com/jasowang/net/tree/vduse-zerocopy The idea is to map the page directly to the userspace if the buffer occupies a full page and usersapce is expected to recycle the page via MADV_DONTNEED. It's far from mature but it can demonstrate the idea somehow. > where vhost-user devices access virtqueues directly in the kernel > space. Eugenio used to work on a POC to bridge vhost-user to vDPA via a dedicated userspace application. He might share more thoughts about this. > The technology does not require any changes to virtio protocol > and vhost-user library. > > The architecture supports vhost-user-rng, input, blk, gpio, can, > sound and console devices. Early support has been provided also for > vhost-user-vsock, i2c and scsi. One important reason why we do device whitelist or feature blacklist for VDUSE is for security. For example, we should not allow the userspace device to do DOS to kernel by not responding to 1) config space write (we disable WCE for block) or 2) any control virtqueue commands (we disable control vq for net). This needs to be explained here as well. > > 2. Updates: > ------- > > Since the last time virtio-loopback was introduced [1], we implemented > the following updates: > - Multi-device support: > - The driver can handle multiple instances of virtio-devices and > connects them with multiple different instances of the vhost-user > devices though one or many instances of the adapter application. > > - Update the memory mapping mechanism (zero copy mechanism between > virtio and vhost-user devices): > - The technology implements a page-fault mechanism which enables > the vhost-user devices to access the vrings buffer located in the > kernel. > > - Update the notification mechanism: > - Notification can be delivered from the virtio-driver directly to > the vhost-user-device (by-passing the adapter application) > > - Add support for more devices: > - The technology added support for vhost-user GPIO, CAN and > Sound device. > - The architecture has become more device-agnostic and the process > of supporting new devices has become a trivial task for most > devices. > > 3. Virtio-loopback vs vDUSE (+ benchmarks): > ------- > > Virtio-loopback and vDUSE technologies serve the same purpose by > trying to define a virtio-based HAL between application and > user-spaces drivers. > > The main differences between the two technologies are: > - Memory mapping mechanism: > - Virtio-loopback implements a zero-copy data sharing mechanism > - vDUSE implements a bouncing buffer mechanism for sharing the data > with the user-space. > - Dependencies to other technologies: > - Virtio-loopback is a simple virtio-transport driver while vDUSE > is relying on vDPA as an upper layer > - Devices supported: > - Virtio-loopback: virtio-blk, virtio-rng, virtio-input, virtio-can, > virtio-gpio, virtio-sound > - vDUSE: virtio-blk and virtio-net > > Performance wise the two technologies seems to behave very similarly > when we measured the throughout for the virtio-block case using the > fio tool [4]. Interesting, any reason for this? As there's a costy bounce buffer operation done for VDUSE. Thanks > > 4. More information: > ------- > > More information and instruction about how to test the design can be > found in repo [5]. > > 5. References: > ------ > > [1] -> https://lore.kernel.org/virtio-dev/CANN35wLsm_RTTKmxFz5jcBujoxfjPwsu37FAw9+W58hjt_nVPQ@xxxxxxxxxxxxxx/ > [2] -> https://gerrit.automotivelinux.org/gerrit/admin/repos/src/virtio/virtio-loopback-driver > [3] -> https://gerrit.automotivelinux.org/gerrit/admin/repos/src/virtio/virtio-loopback-adapter > [4] -> http://www.virtualopensystems.com/en/research/scientific-contributions/virtio-loopback-perf-eval-icai2024/ > [5] -> https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/virtio/virtio-loopback-adapter.git;a=blob;f=Documentation/testing_virtio_loopback_design.md > > Thank you for taking the time to review this RFC, > I would appreciate your feedback and suggestions for improvements. > > Timos Ampelikiotis (1): > VirtIO: Add platform bus driver for loopback virtio device > > MAINTAINERS | 10 + > drivers/virtio/Kconfig | 20 + > drivers/virtio/Makefile | 2 + > drivers/virtio/virtio_loopback.c | 780 +++++++++++++++++ > drivers/virtio/virtio_loopback_transport.c | 924 +++++++++++++++++++++ > include/uapi/linux/virtio_loopback.h | 259 ++++++ > 6 files changed, 1995 insertions(+) > create mode 100644 drivers/virtio/virtio_loopback.c > create mode 100644 drivers/virtio/virtio_loopback_transport.c > create mode 100644 include/uapi/linux/virtio_loopback.h > > -- > 2.34.1 >
