Re: X server in dom0: Bad VBT signature

["Cherry G. Mathew" <cherry.g.mathew%gmail.com@localhost>]

On 4 September 2012 12:25, Manuel Bouyer <bouyer%antioche.eu.org@localhost> 
wrote:
> On Tue, Sep 04, 2012 at 03:32:23PM +0200, Gianluca Guida wrote:
>> 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
>
> Ha yes, that's another possibility.
>

Cool, that would reclaim about 0x100000 bytes of RAM.

>> 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.
>
> The real problem is that X, unlike in-kernel drivers, can't express
> that it wants to access device memory space and not plain RAM. Splitting
> the /dev/mem space in RAM and non-RAM segments is only a workaround for
> that. This workaround works for x86, but one could immagine a hardware
> where this woudln't work.
>

Can we solve this in X's code by working out a clean MI api between
the kernel and the video driver (similar to pci_usrreq.c via
/dev/pcixx) instead of exposing arbitrary mem i/o to userland ?


-- 
~Cherry