Re: X server in dom0: Bad VBT signature

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

On Mon, Sep 03, 2012 at 06:43:34AM +0100, Cherry G. Mathew wrote:
> This was no different from the original code. As far as I understand,
> here's what happens (upto machdep.c -r 1.168)
> - xen_pmap_bootstrap() returns what roughly becomes avail_start
> - avail_start to avail_end is uvm_page_physload()ed as one chunk into uvm
> - pmap_pa_start/end are used as shims to intercept pmap_[k]enter() to
> demarcate the physical address of RAM. Everything outside of this is
> mapped in as machine frames

You're right, UVM doens't know ram below avail_start. This means a bit
of ram is lost (KERNTEXTOFF - KERNBASE). I don't see this as a big
problem.

> - Xen seems to load RAM mappings in the physical address space of dom0
> (ie; the ISA hole is actual addressable RAM in the p2m/m2p tables of
> dom0).
> 
> Currently, this last point is the only issue. Hotplug is going to
> complicate things, but I'm not going to open that can of worms here.

It's not only the ISA hole: there can be memory-mapped devices outside of
the ISA hole. There is the PCI memory space, and some BIOS-provided
data (e.g. ACPI) are at other addressses too.
And yes, there is RAM mapped in dom0's physical space at these addresses,
because in Xen world these ressources are not in physical space, they
are in machine space.

> 
> > 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 guessing both! ktrace shows opening /dev/pcix for device config
> probes and /dev/mem for VRAM (0xa000). This needs to be whittled down
> to the lowest possible set of apertures, imho.

/dev/pciX is only to access PCI config space, I think. I/O space is acceeded
via i386_iopl(3) or x86_64_iopl(3), and memory space via /dev/mem
(and this is where our problem is). The primary adapter may use
only adresses in the ISA hole, but if you have more than one adapter
you're likely to use addresses in PCI memory space.

> > 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.
> 
> So I recalled where I saw this: dev/pci_usrreq.c
> 
> I still think that we can make the abstractions fit better with MI
> ones such as bus_space() and remove the redundant alias-ed pmap_xxx()
> functions in x86/x86/pmap.c and xen/x86/xen_pmap.c

There are still a space where you want to translate physical to
machine addresses using xen_ptom[] before mapping, and one where you don't.
This has to be somewhere. I think pmap is where is it easiest to
centralize, but I'm not against being proven wrong :)

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