Re: X server in dom0: Bad VBT signature

[Gianluca Guida <glguida%tlbflush.org@localhost>]

On Tue, Sep 04, 2012 at 09:19:57AM +0200, Manuel Bouyer wrote:
> On Mon, Sep 03, 2012 at 07:44:23PM -0400, Konrad Rzeszutek Wilk wrote:
> > > 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?
> 
> physical or machine, depending on what the userland process wants.
> 
> > 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?
> 
> I can't see how, as the 2 spaces have overlapping addresses.
> For a domain with 512MB RAM, Xen gives a physical address space of
> 0x0 -> 0x20000000. The ISA hole (for example) is at machine
> address 0x0a0000 -> 0x100000 (there are memory-mapped ressources outside
> this range too). When a process mmaps /dev/mem at 0x0a0000, how do
> you know if it wants the RAM at physical address 0x0a0000 (this address then
> has to be translated to machine address), or a device mapped
> at machine address 0x0a0000 ?

Isn't the problem here considering /dev/mem to be a sort of wrapper of
two linear spaces?
Domain memory should be uniquely identifiable by a linear address, and
this means that we shouldn't have RAM available in the ISA hole.

I just subscribed to this list. Probably out of context, but I hope it
helps.

Gianluca