On 10/17/2023 10:27 PM, Jason Wang wrote:
If we do
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
It's not just one line of check here, the old behavior emulation has to
be done as Eugenio illustrated in the other email.
For vhost-vDPA it's just
if (IOTLB_PERSIST is acked by userspace)
reset_map()
... 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.
-Siwei
For parent, it's somehow similar:
during .reset()
if (IOTLB_PERSIST is not acked by userspace)
reset_vendor_mappings()
Anything I missed here?
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
