vDPA kernel fmk: vDPA bus drivers for kernel subsystem interactions

目录

vhost-vDPA bus driver

design of vhost-vDPA bus driver 

Memory (DMA) mapping with vhost-vDPA

 DMA translation on platform IOMMU

DMA translation on chip IOMMU

virtio-vDPA bus driver

Design of virtio-vdpa bus driver

Memory (DMA) mapping with virtio-vDPA driver

Summary

参考文章

---

vhost-vDPA bus driver

design of vhost-vDPA bus driver 

• vhost
  • historical data path implementation of virtio inside the kernel
  • emulating datapath of virtio devices on host
  • mature uAPIs for setting up kernel data path through vhost device
• vhost-vDPA bus driver
  • new vhost device type on top of the vDPA bus
  • leveraging vhost uAPI 
  • mediating between vhost uAPIs and vDPA bus operations
  • present vhost devices to userspace vhost driver

• perform mediation between vhost uAPI and vDPA bus operations
• vhost subsystem view,
  • another type of vhost device (vhost-vDPA device) with an IOTLB
  • When vDPA device is probed by the vhost-vDPA bus driver,  char device (/dev/vhost-vdpa-X) be created for userspace drivers to accept vhost uAPI
• vhost-vDPA device reuses existing vhost uAPIs

  • Setting device owner (ioctls)

    • each vhost-vdpa device paired with process (owner of this vhost-vdpa device)

    • vhost-vdpa device won’t allow a process other than the owner to change the memory mapping

  • Virtqueue configurations (ioctls)

    • setting up base address, queue size; set or get queue indices

    • vhost-vDPA bus driver translate those commands to vDPA bus operations and send to vDPA device drivers via vDPA bus

  • Setting up eventfd for virtqueue interrupts and kicks (ioctls)

    • vhost use eventfd for relaying the events such as kicks or virtqueue interrupt to userspace.

    • vhost-vDPA bus driver translate those commands to vDPA bus operations and send them to vDPA device driver via vDPA bus

  • Populating device IOTLB

    • vhost IOTLB message write to (or read from) vhost-vdpa char device

    • vhost-vDPA leverages device IOTLB abstraction for vhost devices

    • userspace vhost drivers inform the memory mapping between IOVA and VA.

    • userspace vhost drivers updates vhost-vDPA device on the following types of vhost IOTLB messages

      • VHOST_IOTLB_UPDATE: establish new IOVA->VA mapping in vhost-vDPA device IOTLB.

      • VHOST_IOTLB_INVALIDATE: invalidate existing mapping of IOVA->VA in vhost-vDPA device IOTLB.

      • VHOST_IOTLB_MISS: vhost-vDPA device IOTLB ask for a translation from userspace of IOVA->VA using this message. for future usage when vDPA devices will support demand paging.(类似于openflow报文的miss)

• traditional vhost ioctls designed to set up a datapath for vhost devices

• traditional vhost ioctls doesn’t satisfy the vDPA device abstracted by vDPA bus.

  • need add additional ioctls for the control path in addition to the data path ioctls:

    • Get virtio device ID:  useful for userspace to match a type of device driver to vDPA device

    • Setting and getting device status: allows userspace to control the device status (start and stop)

    • Setting and getting device config space:  allows userspace drivers to access the device specific configuration space

    • Config device interrupt support:  allows vDPA devices to emulate or relay config interrupts to userspace via eventfd.

    • Doorbell mapping:  allows userspace to map the doorbell of a specific virtqueue into its own address space.  eliminate extra cost of relaying doorbell via eventfd. case of VM, saves the vmexit

  • With extension

    • vhost-vDPA bus driver provides full abstraction of vDPA devices.

    • Userspace control the vDPA device as if a vhost device

    • vhost-vDPA bus driver receives userspace requests，perform two actions

      • vhost-vdpa bus driver translate request and forward through vDPA bus.

      • Ask for help from other kernel subsystems to finish request

Memory (DMA) mapping with vhost-vDPA

• vhost-vdpa device DMA abstraction by userspace visible IOTLB.
• userspace driver create or destroy IOVA->VA mapping to make vDPA device work

• IOVA could be

  • Guest Physical Address (GPA) vhost-vDPA as backend for VM without vIOMMU

  • Guest IO Virtual Address (GIOVA)  vhost-vDPA as backend for VM with vIOMMU

  • Virtual Address (VA)  using vhost-vDPA for a userspace direct IO datapath

• depending on where DMA translation done by HW, vhost-vDPA drivers behave differently
• translation can be done on the platform IOMMU or on chip IOMMMU

 DMA translation on platform IOMMU

devices  depend on platform IOMMU for DMA translation

• vhost-vDPA bus driver detects device requirements of platform IOMMU by checking whether the device specific DMA config ops are implemented
• If device specific DMA operations are not implemented that means the device depends on the platform IOMMU.
• During probing of vDPA device on vDPA bus, vhost-vDPA bus driver will probe platform IOMMU that the vDPA device is attached to
• The probing of the platform IOMMU is done through the DMA device (vDPA VF) which is specified during the vDPA device creation
• vhost-vDPA bus driver allocate an IOMMU domain which is dedicated for the vhost-vDPA owner process for isolating DMA from other processes.
• During removal of the vhost-vDPA device, the vhost-vDPA bus driver will destroy the IOMMU domain
• vhost-vDPA device uses IOMMU domain as a handle for requesting mapping to be set up or destroyed in platform IOMMU hardware
• When IOMMU domain is allocated during probing,  vhost-vDPA device ready for receiving DMA mapping requests from userspace through vhost IOTLB uAPI in the following order
  • Userspace writes a vhost IOTLB message to vhost-vDPA char device when the userspace wants to establish/invalidate an IOVA->VA mapping
  • vhost-vDPA device receives the request and converts VA to PA (Physical Address).
    • Note: PA may not be contiguous even if VA is thus a single IOVA to VA mappings could have several IOVA->PA mappings.
  • vhost-vDPA device lock/unlock pages in memory and store/remove mappings of IOVA->PA in it’s IOTLB.
  • vhost-vDPA device ask IOMMU domain to build/remove the IOVA->PA mapping through the IOMMU API.
    • APIs are a unified set of operations that are used for IOMMU drivers to cooperate with other kernel modules for userspace DMA isolation
  • IOMMU domain ask IOMMU driver to perform vendor/platform specific tasks to establish/invalidate mapping in the platform IOMMU HW
• device (vDPA VF) initiate DMA requests with IOVA.  IOVA will be validated and translated by platform IOMMU to PA for real DMA requests

DMA translation on chip IOMMU

•  devices require the DMA translation to be implemented by its own device or driver
• vhost-vdpa bus driver will forward the DMA mapping request to the vDPA bus

• When vhost-vDPA bus driver detects that vDPA DMA bus operations are implemented in the vDPA driver, DMA/IOMMU processing will be done in the level of vDPA device driver
• requires setup of DMA/IOMMU domain for both on-chip IOMMU and platform IOMMU.
• In this case vhost-vDPA driver will not use IOMMU API but rather forward the memory mapping to vDPA device driver through vDPA DMA bus operations

  • vhost-vDPA device receives request and converts VA to PA. 

  • vhost-vDPA device lock/unlock pages in memory and store/remove IOVA->PA mappings in its IOTLB.

  • vhost-vDPA device ask vhost-VDPA bus driver to forward mapping request to vDPA device driver.

  • vDPA device driver use vendor specific methods to set up an embedded IOMMU on the device.

    • When needed, vDPA device drivers need to cooperate with platform IOMMU drivers for necessary setups.

    • means vDPA device driver needs to setup/remove IOVA->IA mappings (IA Intermediate Address) in the on-chip IOMMU and IA->PA mappings in platform IOMMU.

      • IA is defined in vDPA device driver

• When device (vDPA VF) initiates DMA requests with IOVA,  IOVA will be validated and translated by on-chip IOMMU to IA for real DMA requests first.

• Then platform IOMMU will be in charge of translating and validating the IA->PA mapping.

• With the help of IOTLB abstraction, the cooperation with the IOMMU domain and the vDPA device drivers, the vhost-vDPA device presents a unified and hardware agnostic vhost device to the userspace

virtio-vDPA bus driver

Design of virtio-vdpa bus driver

virtio-vDPA bus driver presents a virtio device and leverages kernel virtio drivers

• goal：to enable the kernel virtio drivers to control the vDPA device as if they were virtio devices without any modification
• virtio-vDPA bus driver is used for providing virtio based kernel datapath to the userspace
• virtio-vDPA bus driver will emulate virtio devices on top of vDPA devices
  • Implementing a new vDPA transport (which is the bus abstraction for virtio device) that performs the translation between the virtio bus operations and vDPA bus operations
  • Probing vDPA devices and registering virtio devices on the virtio bus
  • Forwarding the device interrupt to the virtio device.
• virtio-vDPA bus driver be treated as a mediator between the virtio bus and the vDPA bus.
  • From the view of vDPA bus the virtio-vDPA bus driver is a bus driver.
  • From the perspective of the virtio bus the virtio-vDPA bus driver is a virtio device
• Using this abstraction, the virtio device on behalf of the vDPA device can be probed by virtio drivers
  • For example, the vDPA networking devices could be probed by the virtio-net driver and utilized by the kernel networking subsystem eventually
  • Processes can use socket based uAPI to send or receive traffic via vDPA networking devices
  • Processes can use kernel IO uAPI to read and write via vDPA block devices with the help of the virtio-blk driver and the virtio-vDPA bus driver

Memory (DMA) mapping with virtio-vDPA driver

• kernel uses a single DMA domain for all devices owned by itself
• Kernel drivers cooperate with the IOMMU driver for setting up DMA mapping through the DMA API
• Such domain setups are done during the boot process
• virtio-vDPA bus driver only needs to handle DMA map/unmap and no need for caring about IOMMU domain setups
• DMA API requires device handle for finding the IOMMU
• virtio driver uses the parent device of the virtio device as the DMA handle.
• When virtio-vDPA bus driver registers the virtio device to the virtio bus, it will specify the DMA device (usually the PCI device) of the underlying vDPA device as the parent device of the virtio device
• When the virtio driver tries to setup or invalidate a specific DMA mapping, the IOVA->PA mapping will be passed via DMA API to the PCI device (parent device of the virtio device).
• The kernel will then find the IOMMU that the PCI device is attached to and forward the request to the IOMMU driver which talks to the platform IOMMU
• When the vDPA device wants to perform DMA through IOVA, the translation and validation will be done by the IOMMU and the PA will be used in the real DMA to access the buffers owned by the kernel afterwards.

Summary

• describes how vhost-vDPA bus driver and virtio-vDPA bus driver leverage the kernel virtio and vhost subsystems for providing a unified interface for kernel virtio drivers and userspace vhost drivers
• explained differences between platform IOMMU support and chip IOMMU support
  • vhost-vDPA bus driver supports both while virtio-vDPA bus driver only supports platform IOMMU

参考文章

vDPA kernel framework part 2: vDPA bus drivers for kernel subsystem interactions