Re: X server in dom0: Bad VBT signature

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sun, Sep 02, 2012 at 07:12:01PM +0100, Cherry G. Mathew wrote:
> 
> Yeah but that won't solve the abstraction problem, will it ?

No. Solving this needs some changes to userland (namely the X server).
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.
On Xen (and maybe other hardware platforms)this is a problem because these
are distinct addresses spaces, with eventually overlapping ranges.

> If we
> skip the pa address space that needs to pass through to native, we
> lose the RAM allocated there.

Yes, of course.

> Alternatively we can muck with the
> p2m/m2p tables by remapping them elsewhere, *sigh*.

Yes.
Or restore XPMAP_OFFSET.

> > And I'm not sure the addresse X wants to map are in the ISA hole.
> > it may be in PCI memory space too, I guess.
> >
> 
> I'm curious about this - currently we just assume that everything
> above allocated RAM is meant for mem i/o.
> 
> 
> >>
> >> > regular pages mapped in device's memory space, which will likely lead to
> >> > panic or spontaneous reboot.
> >> >
> >>
> >> Will the following fix that: (I know your original code just removed
> >> the uvm management of that range entirely, I'm just looking for an
> >> alternative implementation)
> >
> > No, this has nothing to do with bus_space. I guess the memory addresses
> > that X wants to use are never seen by bus_space, because no driver
> > claims them.
> >
> 
> I thought I saw a bus_space_mmap() somewhere in the uvm mmap codepath,
> maybe I'm confused.
> 
> Perhaps it should be in a future /dev/xf86 driver mmap path.

It's not xf86-specific so a better name is needed :)
but yes, that's the idea.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--