Re: X server in dom0: Bad VBT signature

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

On Tue, Sep 04, 2012 at 12:44:41PM +0200, Manuel Bouyer wrote:
> On Tue, Sep 04, 2012 at 09:14:45PM +0200, Gianluca Guida wrote:
> > On Tue, Sep 04, 2012 at 10:02:14AM +0200, Manuel Bouyer wrote:
> > > On Tue, Sep 04, 2012 at 06:48:02PM +0200, Gianluca Guida wrote:
> > > > Isn't the problem here considering /dev/mem to be a sort of wrapper of
> > > > two linear spaces?
> > > 
> > > Yes it is. In an ideal world the userland process should have a way to
> > > express what space it wants.
> > 
> > TBH, my question is why are we in this position to start with.
> > 
> > Why not get the Xen's port physical machine look what it is in actual
> > hardware, that is one single address space that contains RAM, I/O and
> > other entries?
> 
> because that's not how xen works. Xen gives us a dense PA space,

Nope.

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).
This requires of course handling our own p2m table, not sure if NetBSD
does this currently.
From a quick look at the code, -- it's really quick so I might be wrong
-- NetBSD doesn't really uses the memory_op nor the e820-like
functions in Xen case, and this get us in this situation, which can be
fixed.
Again, I don't really know very well NetBSD's xen implementation, I am
actually looking at that in the spare time in these days, so I might
have missed something important.

Thanks,
Gianluca