[Weidong Han]
> Espen Skoglund wrote:
>> o The fault handler doesn't actually do much right now. It just
>> clears out the fault queue and prints out warnings. I can only
>> suspect that some more code to handle faults more gracefully are
>> somewhere in the pipeline.
>> 
>> The question is what the plans for dealing with DMA translation
>> faults are (i.e., due to accessing unmapped memory or writing to
>> read-only mappings). At the very least the associated driver
>> should have the possibility to somehow be notified about failed
>> transactions due to translation faults. Is something like this
>> being planned for?
>> 
> Pls refer to 3.5 setion of VT-d spec. DMA requests that result in
> remapping faults must be blocked by hardware. The exact method of
> DMA blocking is implementation-specific. Faulting DMA write / read
> requests may be handled in much the same way as hardware handles
> write requests to non-existent memory. So I think our fault handler
> that clears fault queue and prints out warnings is enough.
Yes, I'm aware that faulting DMA remapping transactions are blocked by
the hardware. However, I'm concerned that faulting transactions can
cause malfunctions if not detected by the system. Sure, for read
requests on PCIe the device will notice the error in the completion
status and can handle it apropriately. But how about write requests?
(I don't know if PCIe device will be notified of memory write
failures.) And how about requests from non-PCIe devices?
It may be the case that all DMA translation faults are entirely the
result of device drivers having screwed up and shot themselves in the
foot, and that they should be allowed to repeatedly do so until their
leg falls off. However, I'm not convinced that faulting DMA
translations are always the cause of faulty drivers, in particular if
one starts allowing frontends to more directly talk to the device.
If DMA translation faults can always safely be ignored then I'm happy
to accept that. On the other hand, a device repeatedly raising
translation faults is surely doing something wrong, and bringing it
down might be a good idea.
Anyhow, if all DMA translation faults can be ignored, why then bother
enabling faults in the context entries in the first place?
 eSk
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel