[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.