Since that you get the right value of version register, the phys addr 
which you get from ACPI
should be right. Probably, you should not use device_arena, which kmdb 
might be rejecting to
read/write it for avoiding some side effect. BTW, I am not sure, but you 
can give it a try:

Replace device_arena_alloc() with:

vmem_alloc(), and use heap_arena as the first parameter.

good luck,

-minskey


Lu Baolu 写道:
> Hi Mark and Edward,
>
> Thanks for the replies.
>
> ::vtop reports the right mapping:
>
> [2]> 0xffffff049dd20000::vtop
> virtual ffffff049dd20000 mapped to physical fe710000
>
> I tried "mdb -W" and "::set -o allow_io_access" in kmdb, but both 
> don't work for me.
>
> Thanks,
> -baolu
>
>
>
> On Sat, May 24, 2008 at 3:07 AM, Edward Pilatowicz 
> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
>
>     by default mdb (and kmdb) don't allow you to access device memory.
>     to enable access to io ports in mdb, start it with the -W option.
>
>     i think you should be able to enable access to io ports in kmdb
>     by doing:
>     ::set -o allow_io_access
>     but this doesn't seem to be working for me. perhaps i'm missing
>     something...
>
>     ed
>
>     On Fri, May 23, 2008 at 04:54:51PM +0800, Lu Baolu wrote:
>     > Hi,
>     >
>     > I am writing code in rootnex to implement Intel IOMMU. The
>     register set for
>     > each remapping hardware unit is placed at a 4KB-aligned memory
>     mapped
>     > location. I try to map the register set with an allocated
>     virtual address
>     > space so the CPU can access it.
>     >
>     > My mapping function is put in rootnex_attach(), and the function
>     code is,
>     >
>     > static caddr_t
>     > iommu_mapin_reg(paddr_t addr, size_t len)
>     > {
>     > uint_t pgoffset;
>     > pgcnt_t npages;
>     > caddr_t cvaddr;
>     >
>     > if (len == 0)
>     > return (0);
>     >
>     > pgoffset = addr & MMU_PAGEOFFSET;
>     > npages = mmu_btopr(len + pgoffset);
>     > cvaddr = device_arena_alloc(ptob(npages), VM_NOSLEEP);
>     > if (cvaddr == NULL)
>     > return (0);
>     > hat_devload(kas.a_hat, cvaddr, mmu_ptob(npages), mmu_btop(addr),
>     > PROT_READ | PROT_WRITE, HAT_LOAD_LOCK);
>     >
>     > cmn_err(CE_CONT, "iommu_mapin_reg: 0x%" PRIx64 ", %d @ 0x%" PRIx64
>     > "\n",
>     > (uint64_t)addr, (uint_t)len, (uint64_t)(uintptr_t)cvaddr);
>     >
>     > return (cvaddr + pgoffset);
>     > }
>     >
>     > The output of cmn_err() in above function during boot is,
>     >
>     > iommu_mapin_reg: 0xfe710000 @ 0xffffff049dd20000
>     > iommu_mapin_reg: 0xfe714000 @ 0xffffff049dd25000
>     > iommu_mapin_reg: 0xfe719000 @ 0xffffff049dd26000
>     > iommu_mapin_reg: 0xfe71a000 @ 0xffffff049dd27000
>     > iommu_mapin_reg: 0xfe718000 @ 0xffffff049dd28000
>     >
>     > But when I use mdb to check the mappings:
>     >
>     > [2]> 0xfe710000 \K
>     > 0xfe710000: 10
>     > [2]> 0xffffff049dd20000 /K
>     > kmdb: failed to read data from target: no mapping for address
>     > 0xffffff049dd20000:
>     >
>     > Mdb access the physical address gets the right data (which is a
>     remapping
>     > unit version, 0x10), but the access through virtual address
>     fails. I checked
>     > the onnv source tree and got to know that ioapic register
>     address (start
>     > from 0xfee0000) is mapped in the same way. And mdb can access
>     the register
>     > apace through the virtual address (I have verified this in mdb).
>     >
>     > PS. I didn't use ddi_regs_map_setup() since what I am writing is
>     not a
>     > driver. Also, ddi_regs_map_setup() will at last be routed to
>     rootnex and map
>     > in the similar way as my mapin function.
>     >
>     > Please advice.
>     >
>     > Thanks,
>     > -baolu
>
>     > _______________________________________________
>     > opensolaris-code mailing list
>     > [email protected]
>     <mailto:[email protected]>
>     > http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> opensolaris-code mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
>   

_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to