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

[Oleksandr <olekstysh@xxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel