diff options
author | Si-Wei Liu <si-wei.liu@oracle.com> | 2023-10-21 12:25:16 +0300 |
---|---|---|
committer | Michael S. Tsirkin <mst@redhat.com> | 2023-11-01 16:20:00 +0300 |
commit | a26f2e4e68ee3130e5d5acb4f58807041aaea905 (patch) | |
tree | 249df4cd426a0b1aefd0dc84d4ba2f0a527d0758 /drivers/virtio | |
parent | 4398776f7a6d532c466f9e41f601c9a291fac5ef (diff) | |
download | linux-a26f2e4e68ee3130e5d5acb4f58807041aaea905.tar.xz |
vdpa: introduce .compat_reset operation callback
Some device specific IOMMU parent drivers have long standing bogus
behaviour that mistakenly clean up the maps during .reset. By
definition, this is violation to the on-chip IOMMU ops (i.e. .set_map,
or .dma_map & .dma_unmap) in those offending drivers, as the removal of
internal maps is completely agnostic to the upper layer, causing
inconsistent view between the userspace and the kernel. Some userspace
app like QEMU gets around of this brokenness by proactively removing and
adding back all the maps around vdpa device reset, but such workaround
actually penaltize other well-behaved driver setup, where vdpa reset
always comes with the associated mapping cost, especially for kernel
vDPA devices (use_va=false) that have high cost on pinning. It's
imperative to rectify this behaviour and remove the problematic code
from all those non-compliant parent drivers.
However, we cannot unconditionally remove the bogus map-cleaning code
from the buggy .reset implementation, as there might exist userspace
apps that already rely on the behaviour on some setup. Introduce a
.compat_reset driver op to keep compatibility with older userspace. New
and well behaved parent driver should not bother to implement such op,
but only those drivers that are doing or used to do non-compliant
map-cleaning reset will have to.
Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com>
Message-Id: <1697880319-4937-5-git-send-email-si-wei.liu@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Lei Yang <leiyang@redhat.com>
Diffstat (limited to 'drivers/virtio')
0 files changed, 0 insertions, 0 deletions