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

RE: [Xen-devel] Handling VT-d translation faults


  • To: "Espen Skoglund" <espen.skoglund@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Han, Weidong" <weidong.han@xxxxxxxxx>
  • Date: Fri, 7 Mar 2008 10:08:34 +0800
  • Delivery-date: Thu, 06 Mar 2008 18:10:39 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Ach/x4dDotKnJFN5RNWQ7sMJYRo8lQALXvlw
  • Thread-topic: [Xen-devel] Handling VT-d translation faults

Espen Skoglund wrote:
> I've been looking through the VT-d code trying to get a better grip on
> what's going on internally, and I've got some questions regarding VT-d
> translation faults.
> 
>  o Currently all VT-d faults are handled in the iommu_page_fault()
>    handler.  This is kind of a misnomer since the fault handler must
>    also be able to handle interrupt remapping faults and faults
>    related to lookups for the context entry.  I assume that this
>    naming is just temporary?
> 

I agree iommu_page_fault() is kind of a misnomer. 

>  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.

Randy (Weidong)



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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