linux/drivers/vhost
Si-Wei Liu 4398776f7a vhost-vdpa: introduce IOTLB_PERSIST backend feature bit
Userspace needs this feature flag to distinguish if vhost-vdpa iotlb in
the kernel can be trusted to persist IOTLB mapping across vDPA reset.
Without it, userspace has no way to tell apart if it's running on an
older kernel, which could silently drop all iotlb mapping across vDPA
reset, especially with broken parent driver implementation for the
.reset driver op. The broken driver may incorrectly drop all mappings of
its own as part of .reset, which inadvertently ends up with corrupted
mapping state between vhost-vdpa userspace and the kernel. As a
workaround, to make the mapping behaviour predictable across reset,
userspace has to pro-actively remove all mappings before vDPA reset, and
then restore all the mappings afterwards. This workaround is done
unconditionally on top of all parent drivers today, due to the parent
driver implementation issue and no means to differentiate.  This
workaround had been utilized in QEMU since day one when the
corresponding vhost-vdpa userspace backend came to the world.

There are 3 cases that backend may claim this feature bit on for:

- parent device that has to work with platform IOMMU
- parent device with on-chip IOMMU that has the expected
  .reset_map support in driver
- parent device with vendor specific IOMMU implementation with
  persistent IOTLB mapping already that has to specifically
  declare this backend feature

The reason why .reset_map is being one of the pre-condition for
persistent iotlb is because without it, vhost-vdpa can't switch back
iotlb to the initial state later on, especially for the on-chip IOMMU
case which starts with identity mapping at device creation. virtio-vdpa
requires on-chip IOMMU to perform 1:1 passthrough translation from PA to
IOVA as-is to begin with, and .reset_map is the only means to turn back
iotlb to the identity mapping mode after vhost-vdpa is gone.

The difference in behavior did not matter as QEMU unmaps all the memory
unregistering the memory listener at vhost_vdpa_dev_start( started =
false), but the backend acknowledging this feature flag allows QEMU to
make sure it is safe to skip this unmap & map in the case of vhost stop
& start cycle.

In that sense, this feature flag is actually a signal for userspace to
know that the driver bug has been solved. Not offering it indicates that
userspace cannot trust the kernel will retain the maps.

Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com>
Acked-by: Eugenio Pérez <eperezma@redhat.com>
Message-Id: <1697880319-4937-4-git-send-email-si-wei.liu@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Lei Yang <leiyang@redhat.com>
2023-11-01 09:20:00 -04:00
..
iotlb.c vhost_iotlb: split out IOTLB initialization 2022-05-31 12:44:28 -04:00
Kconfig vhost_task: Allow vhost layer to use copy_process 2023-03-23 12:45:36 +01:00
Makefile vhost: introduce vDPA-based backend 2020-04-02 10:41:40 -04:00
net.c vhost: convert poll work to be vq based 2023-07-03 12:15:13 -04:00
scsi.c vhost-scsi: Spelling s/preceeding/preceding/g 2023-11-01 09:19:59 -04:00
test.c vhost-test: remove meaningless debug info 2023-02-20 19:26:58 -05:00
test.h tools/virtio: Add --reset 2020-06-22 12:34:21 -04:00
vdpa.c vhost-vdpa: introduce IOTLB_PERSIST backend feature bit 2023-11-01 09:20:00 -04:00
vhost.c vhost: Allow null msg.size on VHOST_IOTLB_INVALIDATE 2023-10-18 11:29:56 -04:00
vhost.h vhost: Make parameter name match of vhost_get_vq_desc() 2023-07-03 12:15:15 -04:00
vringh.c vringh: don't use vringh_kiov_advance() in vringh_iov_xfer() 2023-10-04 08:26:48 +01:00
vsock.c vhost_sock: convert to vhost_vq_work_queue 2023-07-03 12:15:13 -04:00