Re: [Xen-devel] Xen virtual IOMMU high level design doc V3

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 17/11/16 15:36, Lan Tianyu wrote:
> 3.2 l2 translation
> 1) For virtual PCI device
> Xen dummy xen-vIOMMU in Qemu translates IOVA to target GPA via new
> hypercall when DMA operation happens.
>
> When guest triggers a invalidation operation, there maybe in-fly DMA
> request for virtual device has been translated by vIOMMU and return back
> Qemu. Before vIOMMU tells invalidation completed, it's necessary to make
> sure in-fly DMA operation is completed.
>
> When IOMMU driver invalidates IOTLB, it also will wait until the
> invalidation completion. We may use this to drain in-fly DMA operation
> for virtual device.
>
> Guest triggers invalidation operation and trip into vIOMMU in
> hypervisor to flush cache data. After this, it should go to Qemu to
> drain in-fly DMA translation.
>
> To do that, dummy vIOMMU in Qemu registers the same MMIO region as
> vIOMMU's and emulation part of invalidation operation in Xen hypervisor
> returns X86EMUL_UNHANDLEABLE after flush cache. MMIO emulation part is
> supposed to send event to Qemu and dummy vIOMMU get a chance to starts a
> thread to drain in-fly DMA and return emulation done.
>
> Guest polls IVT(invalidate IOTLB) bit in the IOTLB invalidate register
> until it's cleared after triggering invalidation. Dummy vIOMMU in Qemu
> notifies hypervisor drain operation completed via hypercall, vIOMMU
> clears IVT bit and guest finish invalidation operation.

Having the guest poll will be very inefficient.  If the invalidation
does need to reach qemu, it will be a very long time until it
completes.  Is there no interrupt based mechanism which can be used? 
That way the guest can either handle it asynchronous itself, or block
waiting on an interrupt, both of which are better than having it just
spinning.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel