Minskey, Thanks.
My target is not to let kmdb access the io register set, but to verify that the map function in my code take effect. So if ::vtop reports the right mapping, thatś all what I want. -baolu On Sun, May 25, 2008 at 9:00 PM, ChaoHong Guo <[EMAIL PROTECTED]> wrote: > > > 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
