... and this reset_map in vhost_vdpa_cleanup can't be negotiable depending on IOTLB_PERSIST. Consider the case where user switches to virtio-vdpa after an older userspace using vhost-vdpa finished running. Even with buggy_virtio_reset_map in place it's unwarranted the vendor IOMMU can get back to the default state, e.g. ending with 1:1 passthrough mapping. If not doing this unconditionally it will get a big chance to break userspace.For vhost-vDPA it's justIf we doIt's not just one line of check here, the old behavior emulation has to
this without a negotiation, IOTLB will not be clear but the Qemu will
try to re-program the IOTLB after reset. Which will break?
1) stick the exact old behaviour with just one line of check
be done as Eugenio illustrated in the other email.
if (IOTLB_PERSIST is acked by userspace)
reset_map()
For parent, it's somehow similar:
during .reset()
if (IOTLB_PERSIST is not acked by userspace)
reset_vendor_mappings()
Anything I missed here?