> From: Xu, Quan > Sent: Thursday, April 07, 2016 3:45 PM > > On April 05, 2016 5:35pm, Jan Beulich <jbeul...@suse.com> wrote: > > >>> On 01.04.16 at 16:47, <quan...@intel.com> wrote: > > > The dev_invalidate_iotlb() scans ats_devices list to flush ATS > > > devices, and the invalidate_sync() is put after dev_invalidate_iotlb() > > > to synchronize with hardware for flush status. If we assign multiple > > > ATS devices to a domain, the flush status is about all these multiple > > > ATS devices. Once flush timeout expires, we couldn't find out which > > > one is the buggy ATS device. > > > > Is that true? Or is that just a limitation of our implementation? > > > > IMO, both. > I hope vt-d maintainers help me double check it.
Just a limitation of our implementation. Now dev_invalidate_iotlb puts all possible IOTLB flush requests to the queue, and then invalidate_sync pushes a wait descriptor w/ timeout to detect error. VT-d spec says one or more descriptors may be fetched together by hardware. So when a timeout is triggered, we cannot tell which flush request actually has problem by reading queue head register. If we change the implementation to one-invalidation-sync-per-request, then we can tell. I discussed with Quan not to go that complexity though. Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
