Re: X server in dom0: Bad VBT signature

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

On Tue, Sep 04, 2012 at 02:29:10PM +0200, Manuel Bouyer wrote:
> On Tue, Sep 04, 2012 at 02:12:39PM +0200, Gianluca Guida wrote:
> > This is only partially true. Xen also gives us a memory map through
> > memory_op hypercall (for dom0, it actually gives us something pretty
> > similar to the host e820).
> > With this information, we can map the I/O space and other non-RAM pieces
> > of memory to identity mapping that access the actual physical memory of
> > the host (I am talking about dom0 case here, clearly).
> 
> And what do you do with ram that Xen did give us at these addresses ?
> remap it somewhere else ?

My memory isn't helping me here, as the last time I looked at this code
in the Linux kernel was in 2009, and then I've stopped working on Xen
for almost two years, but:

IIRC Linux's dom0 kernel gives back the memory to Xen. I will look at
the details later. It should probably be possible to remap the memory in
some other part, though it might be messy as we'll have to carefully
handle the various holes in the e820 map.


> The identity mapping isn't even needed, if the address is not in a
> ram segment it's a machine address.
> 
> But such a hack doesn't solve the underlying problem which is,
> basically, that under Xen, physical and machine addresses are
> different address spaces.
> 

I have trouble following you here. We seem to see the problem from a very
different points of view. And I fail to understand why this should be a
hack.

> 
> 
> > This requires of course handling our own p2m table, not sure if NetBSD
> > does this currently.
> 
> I'm not sure what you mean here. When we get some external page
> (e.g. from a domU) m2p/p2m is updated accordingly.
> If you mean rebuilding a m2p/p2m from scratch, we don't do that.

I meant in the former case. This clearly explain what I was saying about
not having looked deeply at the NetBSD implementation. :-)

Cheers,
Gianluca