Re: X server in dom0: Bad VBT signature

["Cherry G. Mathew" <cherry.g.mathew%gmail.com@localhost>]

On 2 September 2012 21:42, Mouse <mouse%rodents-montreal.org@localhost> wrote:
>> 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 different.
>
> Sounds as though Xen is the problem, in that it is putting two
> different things (RAM and memory-mapped hardware) at the same
> (emulated-)physical address.  Or am I still misunderstanding?
>
>>> Well, on the SPARC, there are alternative memory access instructions
>>> which take an address space identifier;
>> Can address space identifier be used by non-privilegied instructions?
>
> As far as I can tell it cannot; the instructions in question (sta, lda,
> stba, lduba, etc) are, I think, defined to fault if attempted, at all,
> from nonprivileged mode.
>
>> If so, it could be an example for an extended /dev/mem
>
> Maybe.  I'm not sure what your extended /dev/mem's interface would look
> like.
>
> As I understand it, it's not possible to set things up so that there is
> a virtual address that, when used with the ordinary load/store
> instructions, turns into alternative address space accesses; this means
> that there is nothing mmap() could possibly return that would look like
> memory but access an alternative address space.  The only way I can see
> to do this would be to return a no-access page to userland and trap to
> emulator code in the kernel for every access.
>
> It would, concetpually, be possible for the pmap to maintain multiple
> address spaces for a process, and have some kind of asimmap() that
> returns a `pointer' useful only with the correct ASI value and
> userland-usable lda/sta/etc instructions.  But those instructions are
> only hypothetical, so I see no benefit to following this line of
> thought, unless perhaps some other architecture has similar facilities
> that are usable by userland.  Furthermore, as far as I know, the ASI
> memory access instructions have nothing like an MMU between the address
> and what it accesses, making asimmap() not only impossible but also
> unnecessary.
>

I'm not sure if we should over-abstract for just X. imho, X should
have a clear api for it's userspace device mapping foo.

-- 
~Cherry