Re: [RFC v2 1/1] memory: Delete assertion in memory_region_unregister_iommu_notifier
On Fri, 2020-07-03 at 15:24 +0800, Jason Wang wrote:
On 2020/7/2 下午11:45, Peter Xu wrote:
> On Thu, Jul 02, 2020 at 11:01:54AM +0800, Jason Wang wrote:
> > So I think we agree that a new notifier is needed?
> Good to me, or a new flag should be easier (IOMMU_NOTIFIER_DEV_IOTLB)?
That should work but I wonder something as following is better.
Instead of introducing new flags, how about carry the type of event in
the notifier then the device (vhost) can choose the message it want to
process like:
static vhost_iommu_event(IOMMUNotifier *n, IOMMUTLBEvent *event)
{
switch (event->type) {
case IOMMU_MAP:
case IOMMU_UNMAP:
case IOMMU_DEV_IOTLB_UNMAP:
...
}
Thanks
Hi!
Sorry, I thought I had this clear but now it seems not so clear to me. Do you mean to add
that switch to the current
vhost_iommu_unmap_notify, and then the "type" field to the IOMMUTLBEntry? Is
that the scope of the changes, or there is
something I'm missing?
If that is correct, what is the advantage for vhost or other notifiers? I understand that
move the IOMMUTLBEntry (addr,
len) -> (iova, mask) split/transformation to the different notifiers implementation
could pollute them, but this is even a deeper change and vhost is not insterested in other
events but IOMMU_UNMAP, isn't?
On the other hand, who decide what type of event is? If I follow the backtrace of the
assert in
https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg01015.html, it seems to me that
it should be
vtd_process_device_iotlb_desc. How do I know if it should be IOMMU_UNMAP or
IOMMU_DEV_IOTLB_UNMAP? If I set it in some
function of memory.c, I should decide the type looking the actual notifier, isn't?
Thanks!