Re: [Xen-devel] [PATCH V2 6/6] iommu/arm: Add Renesas IPMMU-VMSA support

[Oleksandr <olekstysh@gmail.com>]

Hi, Julien


>>
>>     What will actually happen if the transaction fail again? For 
>> instance,
>>     if the IOVA was not mapped. Will you receive the interrupt again?
>>     If so, are you going to make the flush again and again until the 
>> guest
>>     is killed?
>>
>>
>> This is a good question. I think, if address is not mapped, the 
>> transaction will fail again and we will get the interrupt again. Not 
>> sure, until the guest is killed or until the driver in the guest 
>> detects timeout and cancels DMA. Let's consider the worst case, until 
>> the guest is killed.
>>
>> So my questions are what do you think would be the proper driver's 
>> behavior in that case? Do nothing and don't even try to resolve error 
>> condition/unblock translation at the first page fault, or give it a 
>> few attempts, or unblock every time.
>
> I will answer back with a question here. How is the TLB flush is going 
> to unblock anything? The more you are not fixing any error condition 
> here... And the print "Unhandled fault" just afterwards clearly leads 
> to think that there are very little chance the fault has been resolved.

Now I understand your point. This really makes sense.


>
>> How does the SMMU driver act in such situation?
>
> I have CCed Robin who knows better than me the SMMU driver. Though it 
> is the Linux one but Xen is based on it.
>
> From my understanding, it is implementation defined whether the SMMU 
> supports stalling a transaction on fault. AFAICT, the current Xen 
> driver will just terminate the transaction and therefore the client 
> transaction behave as RAZ/WI.

I got it. So, sounds like the client won't be able to do something bad, 
and we won't receive an interrupt storm here in Xen.


>
>
>>
>> Quite clear, if we get a fault, then address is not mapped. I think, 
>> it can be both: by issuing wrong address (baggy driver, malicious 
>> driver) or by race (unlikely). If this is the real race (device hits 
>> brake-before-make, for example), we could give it another attempt, 
>> for example. Looks like we need some mechanism to deploy faulted 
>> address to P2M code (which manages page table) to analyze? Or it is 
>> not worth doing that?
>
> You seem to speak about break-before-make as it was an error. 
> Break-Before-Make is just a sequence to prevent the TLB walker to 
> cache both old and new mapping at the same time. At a given point the 
> IOVA translation can only be:
>    1) The old physical address
>    2) No address -> result to a fault
>    3) The new physical address
>
> 1) and 3) should not result to a fault. 2) will result to a fault but 
> then the TLB should not cache invalid entry, right?

right.


>
> In order to see 2), we always flush the TLBs after removing the old 
> physical address.
>
> Unfortunately, some of the IOMMUs are not able to restart 
> transactions, Xen currently avoids to flush the TLBs after 2). So you 
> may be able to see both mapping at the same time.
>
> Looking at your driver, I believe you would have the flag IMSTR.MHIT 
> (multiple tlb hits) set because this is the condition we are trying to 
> prevent with break-before-make. The comment in the code leads to think 
> this is a fault error, so I am not sure why you would recover here...
>
> If your IOMMU is able to stall transaction, then it would be best if 
> we properly handle break-before-make with it.

Thank you for the detailed answer. I would like to say that I have never 
seen Multiple tlb hits error raised by IPMMU in Xen.


>
> Overall, it feels to me the TLB flush is here for a different reason.


I will drop this TLB flush from interrupt handler until clarified.


-- 
Regards,

Oleksandr Tyshchenko


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel