|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v9 2/3] VT-d: wrap a _sync version for all VT-d flush interfaces
>>> On 07.04.16 at 09:44, <quan.xu@xxxxxxxxx> wrote:
> On April 05, 2016 5:35pm, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>> >>> On 01.04.16 at 16:47, <quan.xu@xxxxxxxxx> wrote:
>> > +{
>> > + queue_invalidate_context(iommu, did, source_id,
>> > + function_mask, granu);
>> > +
>> > + return invalidate_sync(iommu);
>> > +}
>>
>> Further down you replace the only call to
>> queue_invalidate_context() - why keep both functions instead of just making
> the
>> existing one do the sync? (That would the likely also apply to
>> qinval_device_iotlb() and others below.)
>>
>
> It is optional.
> I think:
> 1. in the long term, we may need no _sync version.
> 2. At least, the current wrap looks good to me. e.g.
> queue_invalidate_context() is for context-cache Invalidate Descriptor, and
> the
> invalidate_sync() is for Invalidation Wait Descriptor. It is much clearer.
I don't really agree, but will leave it to the VT-d maintainers to judge.
>> > + if ( ret )
>> > + return ret;
>> > +
>> > if ( flush_dev_iotlb )
>> > ret = dev_invalidate_iotlb(iommu, did, addr, size_order,
>> > type);
>> > - rc = invalidate_sync(iommu);
>> > - if ( !ret )
>> > - ret = rc;
>> > }
>>
>> I think leaving the existing logic as is would be better - best effort
> invalidation
>> even when an error has occurred.
>>
>
> I have an open:
> As vt-d spec(:Queued Invalidation Ordering Considerations) said,
> 1. If the Fence(FN) flag is 1 in a inv_wait_dsc, hardware must execute
> descriptors following the inv_wait_dsc only after wait command is completed.
> 2. when a Device-TLB invalidation timeout is detected, hardware must
> not complete any pending inv_wait_dsc commands.
> In current code, the Fence(FN) is always 1.
> if a Device-TLB invalidation timeout is detected, this additional
> inv_wait_dsc is not completed.
> __iiuc__,
> the new coming descriptors, in that queue, _might_ be not executed any more,
> waiting for this additional inv_wait_dsc which is not completed.
> is it true?
That's not a question to me, is it?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |