dtrace discuss - Aug 2007 - Possible useful feature for dtrace...

Although there are a large number of very useful built in actions
in dtrace, I just found myself wishing for something new.

When trying to diagnose an I/O problem (specifically with
ddi_dma_buf_bind_handle() one gets a series of DMA
cookies which are DMA addresses rather than virtual
addresses.  It would have been nice to be able to
examine the memory using the DMA (or in this case
on an AMD64 box, physical) address.  Being
able to specify physical addresses and possible
something like bmapin()/bmapout() would have
been very useful.

I didn''t see anything in the manual that seemed to cover it, but
as always I would be happy to be told that I simply missed it.

Brian,
      if I''m wrong then I hope someone jumps in and corrects me,
but here''s how I understand it.....

there are, or can be, multiple IO tlbs in a system, and which IO-tlb
a particular DMA goes through isn''t always obvious. before
`bmapin''
can be spec''ed out, we''ld have to figure out how to find which
is
the appropriate IO-tlb, and figure out a way to specify that to the
`bmapin'' function.

HTMS (..., and, hope I''m close to the mark)

-Pete Lawrence.






 D. Horn wrote On 08/01/07 01:44 PM,:
> Although there are a large number of very useful built in actions
> in dtrace, I just found myself wishing for something new.
> 
> When trying to diagnose an I/O problem (specifically with
> ddi_dma_buf_bind_handle() one gets a series of DMA
> cookies which are DMA addresses rather than virtual
> addresses.  It would have been nice to be able to
> examine the memory using the DMA (or in this case
> on an AMD64 box, physical) address.  Being
> able to specify physical addresses and possible
> something like bmapin()/bmapout() would have
> been very useful.
> 
> I didn''t see anything in the manual that seemed to cover it, but
> as always I would be happy to be told that I simply missed it.
> 
> 
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

Peter Lawrence wrote:
> Brian,
>       if I''m wrong then I hope someone jumps in and corrects me,
> but here''s how I understand it.....
>
> there are, or can be, multiple IO tlbs in a system, and which IO-tlb
> a particular DMA goes through isn''t always obvious. before
`bmapin''
> can be spec''ed out, we''ld have to figure out how to find
which is
> the appropriate IO-tlb, and figure out a way to specify that to the
> `bmapin'' function.
>   
Well, all that sort of assumes an IOMMU (such as the SPARC bases systems 
typically
have).  Even so, bpmapin() could check to see if there is an IOMMU 
resource (tlb, pte, whatever)
available - no sleeping now) and create a mapping if possible or return 
failure if not.  I realize
that there are problems to be solved here, but that''s why they pay us 
the "big bucks".

I think it might be an easier problem to be able to specify physical 
memory (as needed
for platforms without an IOMMU).

Brian
> HTMS (..., and, hope I''m close to the mark)
>
> -Pete Lawrence.
>
>
>
>
>
>
>  D. Horn wrote On 08/01/07 01:44 PM,:
>   
>> Although there are a large number of very useful built in actions
>> in dtrace, I just found myself wishing for something new.
>>
>> When trying to diagnose an I/O problem (specifically with
>> ddi_dma_buf_bind_handle() one gets a series of DMA
>> cookies which are DMA addresses rather than virtual
>> addresses.  It would have been nice to be able to
>> examine the memory using the DMA (or in this case
>> on an AMD64 box, physical) address.  Being
>> able to specify physical addresses and possible
>> something like bmapin()/bmapout() would have
>> been very useful.
>>
>> I didn''t see anything in the manual that seemed to cover it,
but
>> as always I would be happy to be told that I simply missed it.
>>
>>
>> _______________________________________________
>> dtrace-discuss mailing list
>> dtrace-discuss at opensolaris.org
>>     
>
>