Hi Eric, >-----Original Message----- >From: Eric Auger <eric.au...@redhat.com> >Subject: Re: [PATCH] hw/virtio/vhost: Disable IOTLB callbacks when IOMMU gets >disabled ... >>>>>> vtd_address_space_refresh_all() will basically disable the iommu >>>>>> memory region. It looks not sufficient to trigger the region_del >>>>>> callback, maybe we should delete the region or introduce listener >>>>>> callback? >>>>> This is exactly the code path which is entered in my use case. >>>>> >>>>> vtd_address_space_refresh_all(s) induces the vhost_iommu_region_del. But >>> given the current implement of this latter the IOTLB callback is not unset >>> and >the >>> kernel IOTLB is not refreshed. Also as I pointed out the hdev->mem->regions >are >>> not updated? shouldn't they. Can you explain what they correspond to? >>>> Adding Peter for more ideas. >>>> >>>> I think it's better to find a way to trigger the listener here, probably: >>>> >>>> 1) add/delete the memory regions instead of enable/disable >>> sorry I don't understand what you mean. The vhost_iommu_region_del call >>> stack is provided below [1]. Write to the intel iommu GCMD TE bit >>> induces a call to vhost_iommu_region_del. This happens before the >>> vhost_dev_stop whose call stack is provided below [2] and originates >> >from a bus reset. >>> We may have inflight IOTLB miss requests happening between both. >>> >>> If this happens, vhost_device_iotlb_miss() fails because the IOVA is not >>> translated anymore by the IOMMU and the iotlb.translated_addr returned >>> by address_space_get_iotlb_entry() is not within the registered >>> vhost_memory_regions looked up in vhost_memory_region_lookup(), hence >>> the "Fail to lookup the translated address" message. >>> >>> It sounds wrong that vhost keeps on using IOVAs that are not translated >>> anymore. It looks we have a reset ordering issue and this patch is just >>> removing the sympton and not the cause. >>> >>> At the moment I don't really get what is initiating the intel iommu TE >>> bit write. This is a guest action but is it initiated from a misordered >>> qemu event? >> During reboot, native_machine_shutdown() calls >x86_platform.iommu_shutdown() >> to disable iommu before reset. So Peter's patch will not address your issue. > >Exactly I see the initial IOMMU disable comes from this guest code path >(native_machine_shutdown). Indeed this is unrelated to Peter's series. >Then I see that vIOMMU is reset and then vhost_dev_stop is called (this >is related to Peter's series).
Agree. Thanks Zhenzhong
