https://bugzilla.novell.com/show_bug.cgi?id=422081
User lverhaegen@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=422081#c9
--- Comment #9 from Luc Verhaegen
Unfortunately I have a hard time understanding #3: How can the frame buffer validly live at (physcial) address 0?
All of the physical RAM sitting off the CPU starts at address 0, the CPUs memory controller sees all of it, including the bit reserved for the framebuffer. The BIOS, yes, through E820, just doesn't mention that reserved part (which always sits at the top of this physical ram).
/dev/mem under Xen is somewhat different from native for obvious reasons: It doesn't allow you to access RAM, only MMIO regions (as reported by BIOS INT 15 Fn E820) can be accessed (and the region mmap()-ed must be consisting of only MMIO, there may not be any RAM portions, but that's probably not the problem here).
X maps memory, any memory, through /dev/mem. I understand that Xen changes things and makes it impossible to use direct RAM access for FB. But this still leaves me wondering: how does X map a memory BAR on our graphics device if only MMIO BARs are accessible? Why are you not running into issues with other drivers? Anyway, for my driver, i am looking into two things: * Is there an easy way for me, an X driver, to tell that Xen is active, so that i can go and map the PCI BAR instead. * Is there a way for me to still map a part of physical memory? Direct RAM access really is a night and day difference on this hardware. Any read or write to the FB then becomes a simple copy from one bit of RAM to the other. Without direct access, any read/write would uselessly loop the same data over the HT busses to the northbridge. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.