|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 08/10] vt-d/ept: propagate IOMMU Device-TLB flush error up to EPT update.
>>> On 10.05.16 at 16:58, <George.Dunlap@xxxxxxxxxxxxx> wrote:
> On Tue, May 10, 2016 at 10:09 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 06.05.16 at 10:54, <quan.xu@xxxxxxxxx> wrote:
>>> --- a/xen/arch/x86/mm/p2m-ept.c
>>> +++ b/xen/arch/x86/mm/p2m-ept.c
>>> @@ -832,7 +832,8 @@ out:
>>> need_modify_vtd_table )
>>> {
>>> if ( iommu_hap_pt_share )
>>> - iommu_pte_flush(d, gfn, &ept_entry->epte, order,
> vtd_pte_present);
>>> + ret = iommu_pte_flush(d, gfn, &ept_entry->epte,
>>> + order, vtd_pte_present);
>>> else
>>> {
>>> if ( iommu_flags )
>>
>> Looking at this in conjunction with patch 3, I can't see where "ret"
>> would get consumed.
>
> Hmm, and here I see where "rc == 0" might be a better option than
> "entry_written".
>
> If we know rc is zero, we can just use rc here instead of 'ret', and I
> think everything falls out.
>
> If rc is not zero, then we have to do this "if ( !rc ) rc = ret;"
> business, which seems a bit silly to do when we know it's zero and
> don't expect that to change.
>
> On the other hand, using rc *without* actually checking that it's zero
> seems like asking for trouble.
>
> So perhaps it would be better if we take your advice for patch 3, and
> then use 'rc' here?
Ah, yes, that's a good 2nd reason.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |