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 12:34:43PM +0200, Manuel Bouyer wrote:
> On Mon, Sep 03, 2012 at 06:16:07AM -0400, Konrad Rzeszutek Wilk wrote:
> > 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?
> 
> I don't think: the problem here is not with the p2m table.
> The problem is to identify, when the pmap module gets a request to
> map a an address, if this is a PA (which has to be translated to a MA), or
> if it's already a MA.
> Device drivers requests are already identified as being MA (thanks to the
> bus_space interface, driver requests have their own path separate from
> VM requests). The problem is when a mapping request comes from userland
> via /dev/mem: we don't know if it is a PA or a MA (it depends on who is
> doing the request) and as both spaces uses the same addresses there
> are conflicts.

Right, but the address that is provided I presume is a physical address?
And based on that, and on the E820 (where that data is plugged in the
P2M array/tree), you can figure out whether to treat this as MA or PA?
> 
> -- 
> Manuel Bouyer <bouyer%antioche.eu.org@localhost>
>      NetBSD: 26 ans d'experience feront toujours la difference
> --


Home | Main Index | Thread Index | Old Index