[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: X server in dom0: Bad VBT signature
On Dec 19, 3:31am, Mouse wrote:
} > The abstraction problem is that /dev/mem is used to access both real
} > RAM by physical address, and memory-mapped devices. On real x86 this
} > is not an issue because it's the same address space.
} I don't really know x86, so it's entirely possible I've got this all
} confused. But I thought there were two I/O address spaces, one
} memory-mapped and another one, with a much smaller address space (one
} byte?), which uses different instructions. Am I misremembering?
} Confusing with some other CPU?
Yes, there are two. With memory mapped I/O, an I/O device will
decode memory lines and map them to device registers and/or device
memory (i.e. a frame buffer on a video card, or packet buffers on a
NIC, ROMs, etc.). These are accessed just like any other "memory".
I/O accesses are done using inb (IN Byte), outb (OUT Byte), inw (IN
Word), outw (OUT Word), etc. instructions. The address range is 1024
(0x0 - 0xFFF). I don't recall the exact size of the address space, it
may wrap in there.
} > On Xen (and maybe other hardware platforms)this is a problem because
} > these are distinct addresses spaces, with eventually overlapping
} > ranges.
} Well, on the SPARC, there are alternative memory access instructions
} which take an address space identifier; they're not used for normal
} device access, though, perhaps in part because they are privileged-only
} and thus can't be used for user-mode device access. (They're used for
} things like accessing the MMU hardware - segment maps, for example, or
} cache flushes.)
x86 MMUs don't have the concept of ASIDs or contexts.
} But I doubt the SPARC is very relevant to Xen per se...though it's
} probably not irrelevant to the design of /dev/mem.
Xen is x86 only, but apparently ARM support is in developement.
}-- End of excerpt from Mouse
Main Index |
Thread Index |