Port-xen archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: X server in dom0: Bad VBT signature
On Mon, Sep 03, 2012 at 09:32:20AM +0200, Manuel Bouyer wrote:
> 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.
In Linux upstream we fixed this by adding an extra bit to the PFN in the
P2M lookup table - an IDENTITY_FRAME_BIT (1<<63) that would identity
said PFN->MFN as a 1:1. During bootup when we scan the E820 we would
mark all everything that is not E820_RAM (and E820_UNUSUABLE) as such
(including the gaps).
Granted there was also some underlaying changes in the technology - we
changed the P2M from an array to be an tree - this way we could replace
swatches of empty space in the tree to point to an 'p2m_identity' leaf.
Anyhow, the point was that with this - we could omit some of the changes
of having to identity various drivers that assume that PFN == MFN and
when they request a PTE we would insert the proper mfn (in the case of
MMIO space that would be the pfn).
Could that solve this problem?
Home |
Main Index |
Thread Index |
Old Index