|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v7 2/2] VT-d: Fix vt-d Device-TLB flush timeout issue
> From: Xu, Quan
> Sent: Wednesday, March 23, 2016 11:30 AM
>
> >
> > Yes, still inconsistent. As I said, you put invalidation sync within
> > dev_invalidate_iotlb, while for all other IOMMU invalidations the sync is
> > put
> > after. Below would be consistent then:
> >
> > if ( flush_dev_iotlb )
> > ret = dev_invalidate_iotlb(iommu, did, addr, size_order, type);
> > rc = dev_invalidate_iotlb_sync(...);
> > if ( !ret )
> > ret = rc;
> >
> Kevin,
> now I doubt that I should put invalidation sync within
> dev_invalidate_iotlb, which was also
> your suggestion.
> As the dev_invalidate_iotlb() is invalidation for all of domain's ATS
> devices. If in this
> consistent way, we couldn't
> Find which ATS device flush timed out, then we need to hide all of domain's
> ATS devices.
> Do you recall it?
> Also I think it is reluctant to put invalidate_sync within
> queue_invalidate_iotlb() for
> consistent issue.
> Quan
Yes I recall this story.
What about doing this? Let's wrap a _sync version for all flush interfaces,
like below:
static int queue_invalidate_context_sync(...)
{
queue_invalidate_context(...);
return invalidate_sync(...);
}
Then invoke _sync version at all callers, e.g.:
static int flush_context_qi(...)
{
...
if ( qi_ctrl->qinval_maddr != 0 )
ret = queue_invalidate_context_sync(...);
}
similarly we'll have dev_invalidate_iotlb_sync for device IOTLB flush.
It simplifies caller logic and make code more readable. :-)
Thanks
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |