[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <695670fd-6762-42d3-b38c-fb347c8beb1d@oracle.com>
Date: Thu, 19 Oct 2023 15:57:51 -0700
From: Si-Wei Liu <si-wei.liu@...cle.com>
To: Jason Wang <jasowang@...hat.com>
Cc: Eugenio Perez Martin <eperezma@...hat.com>, mst@...hat.com,
xuanzhuo@...ux.alibaba.com, dtatulea@...dia.com,
virtualization@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] vhost-vdpa: reset vendor specific mapping to initial
state in .release
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?
Powered by blists - more mailing lists