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
