[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: X server in dom0: Bad VBT signature
On Sun, Sep 02, 2012 at 03:24:00PM -0400, 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?
No, that's it. it's the memory-mapped address space which is
causing problem for Xen, because the physical addresses are not real
machine addresses, they are translated by the hypervisor, and may have
the same address as real machine address but point to something
So when the X server requests (via /dev/mem I guess) to map physical
address e.g. 0x100000, we don't know if it's 0x100000 in the
pseudo-physical address space (and so is has to be translated to machine
address) or if it's already a machine address.
> > 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.)
> But I doubt the SPARC is very relevant to Xen per se...though it's
> probably not irrelevant to the design of /dev/mem.
Can address space identifier be used by non-privilegied instructions ?
If so, it could be an example for an extended /dev/mem
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
NetBSD: 26 ans d'experience feront toujours la difference
Main Index |
Thread Index |