Re: [Xen-devel] [PATCH v4 0/3] VT-d Device-TLB flush issue

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Xu, Quan
> Sent: Wednesday, December 23, 2015 4:26 PM
> 
> This patches are based on Kevin Tian's previous discussion 'Revisit VT-d 
> asynchronous
> flush issue'.
> Fix current timeout concern and also allow limited ATS support in a light way:
> 
> 1. Check VT-d Device-TLB flush error.
>    This patch checks all kinds of error and all the way up the call trees of 
> VT-d Device-TLB
> flush.
> 
> 2. Reduce spin timeout to 1ms, which can be boot-time changed with
> 'iommu_qi_timeout_ms'.
>    For example:
>            multiboot /boot/xen.gz ats=1 iommu_qi_timeout_ms=100
> 
> 3. Fix vt-d Device-TLB flush timeout issue.
>     Now if IOTLB/Context/IETC flush is timeout, panic hypervisor. The coming 
> patch
>     set will fix it.

remove above sentence which is not related to this patch.

> 
>     If Device-TLB flush is timeout, we'll hide the target ATS
>     device and crash the domain owning this ATS device.
> 
>     If impacted domain is hardware domain, just throw out a warning.
> 
>     The hided Device will be disallowed to be further assigned to
>     any domain.

hided -> hidden. Device -> device.

> 
> --
> 
>  * DMAR_OPERATION_TIMEOUT should be also chopped down to a low number of
> milliseconds.
>    As Kevin Tian mentioned in 'Revisit VT-d asynchronous flush issue', We 
> also confirmed
> with hardware team
>    that 1ms is large enough for IOMMU internal flush. So I can change
> DMAR_OPERATION_TIMEOUT from 1000 ms to 1 ms.
> 
>    IOMMU_WAIT_OP() is only for VT-d registers read/write, and there is also a 
> panic. We
> need a further discussion
>    whether or how to remove this panic in next patch set.
> 
>  * if IOTLB/Context/IETC flush is timeout, panic hypervisor. The coming patch 
> set will fix
> it.

for all above, enough to say TODO tasks based on your summary earlier:

   - context/iotlb flush error. (need 2 ~ 3 weeks)
   - iec flush error. (need 3 ~ 4 weeks)

as I commented in another thread, let's discuss them when you have new
code ready.

Thanks
Kevin

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