Re: X server in dom0: Bad VBT signature

[jnemeth%victoria.tc.ca@localhost (John Nemeth)]

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