Frame buffer mmap not working in pvops dom0

Frame buffer mmap not working in pvops dom0

[Daniel De Graaf]

I'm trying to confirm the fix to the VESA fbdev mmap issue that was
brought up a few months ago
(http://marc.info/?l=xen-devel&m=126842551306571&w=2). The wiki page at
http://wiki.xensource.com/xenwiki/XenPVOPSDRM says that this bug should
be fixed, but doesn't point to a patch for the fix. I am still able to
reproduce the issue both on real hardware and by running Xen under qemu
(using cirrusfb on the dom0). Eamon (the original reporter) has also not
been able to confirm a fix.

I'm currently testing using Xen 4.1 built from hg 21831:6bebaf40e925 and
a pvops dom0 from xen/stable-2.6.32.x revid c0a00fbe.

So far, I've been able to determine that an mmap requesting multiple
pages from /dev/fb0 will result in page table entries all pointing to
the same physical page, which is not in the framebuffer address space.
Writing to the mapped page ends up corrupting parts of kernel memory.
I'd be happy to run further tests, try patches, or provide more
information if needed.

-- 

Daniel De Graaf
National Security Agency

Re: Frame buffer mmap not working in pvops dom0

[Pasi Kärkkäinen]

On Wed, Jul 21, 2010 at 09:47:57AM -0400, Daniel De Graaf wrote:
> I'm trying to confirm the fix to the VESA fbdev mmap issue that was
> brought up a few months ago
> (http://marc.info/?l=xen-devel&m=126842551306571&w=2). The wiki page at
> http://wiki.xensource.com/xenwiki/XenPVOPSDRM says that this bug should
> be fixed, but doesn't point to a patch for the fix. I am still able to
> reproduce the issue both on real hardware and by running Xen under qemu
> (using cirrusfb on the dom0). Eamon (the original reporter) has also not
> been able to confirm a fix.
> 
> I'm currently testing using Xen 4.1 built from hg 21831:6bebaf40e925 and
> a pvops dom0 from xen/stable-2.6.32.x revid c0a00fbe.
> 
> So far, I've been able to determine that an mmap requesting multiple
> pages from /dev/fb0 will result in page table entries all pointing to
> the same physical page, which is not in the framebuffer address space.
> Writing to the mapped page ends up corrupting parts of kernel memory.
> I'd be happy to run further tests, try patches, or provide more
> information if needed.
> 

I guess many (most?) graphics related fixes are in Konrad's git tree..

-- Pasi

Re: Frame buffer mmap not working in pvops dom0

[Konrad Rzeszutek Wilk]

[-- Attachment #1: Type: text/plain, Size: 1966 bytes --]

On Wed, Jul 21, 2010 at 05:16:13PM +0300, Pasi Kärkkäinen wrote:
> On Wed, Jul 21, 2010 at 09:47:57AM -0400, Daniel De Graaf wrote:
> > I'm trying to confirm the fix to the VESA fbdev mmap issue that was
> > brought up a few months ago
> > (http://marc.info/?l=xen-devel&m=126842551306571&w=2). The wiki page at

Weird. I don't remember seeing that e-mail..

> > http://wiki.xensource.com/xenwiki/XenPVOPSDRM says that this bug should
> > be fixed, but doesn't point to a patch for the fix. I am still able to
> > reproduce the issue both on real hardware and by running Xen under qemu
> > (using cirrusfb on the dom0). Eamon (the original reporter) has also not
> > been able to confirm a fix.
> > 
> > I'm currently testing using Xen 4.1 built from hg 21831:6bebaf40e925 and
> > a pvops dom0 from xen/stable-2.6.32.x revid c0a00fbe.
> > 
> > So far, I've been able to determine that an mmap requesting multiple
> > pages from /dev/fb0 will result in page table entries all pointing to
> > the same physical page, which is not in the framebuffer address space.
> > Writing to the mapped page ends up corrupting parts of kernel memory.
> > I'd be happy to run further tests, try patches, or provide more
> > information if needed.

Goodies. Let me fix up a tree that cleanly merges with Jeremy's xen/next
(or xen/stable-2.6.32.x) and give you a go with that. And then from
there we can come up with a fix.

Can you tell me how you came up with the analysis? (that should speed up
finding the culprit). Any serial/dmesg outputs would be appreciated.

> > 
> 
> I guess many (most?) graphics related fixes are in Konrad's git tree..

<nods>

Daniel,

I honestly don't remember which patch I thought fixed it. But I do know
that when the /dev/fb0 was backed by DRM (nvidia) it worked (I used the 
below program).

Granted now that I tested it with fbxine and it hangs with a Xen error.
Let me start using Eamon's program.


[-- Attachment #2: fb_test.c --]
[-- Type: text/plain, Size: 1525 bytes --]

#include <stdio.h>
#include <errno.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <fcntl.h>
#include <ctype.h>
#include <linux/fb.h>

static char filename[] = "/dev/fb0";
int main(int argc, char *argv[])
{
	struct fb_var_screeninfo screeninfo;
	int fd = -1;
	int rc;
	unsigned char *fbuf;
	struct stat buf;
	int row, column;
	int i;
	int len;

	printf("Starting..[%s]\n", filename);

	fd = open(filename, O_RDWR);
	if (fd <= 0) {
		printf("Could not open; err: %d\n", errno);
		return errno;
	}
	if (stat(filename, &buf) != 0) {
		printf("Could not open; err: %d\n", errno);
		return errno;
	}

	printf("%s: len:%d\n", filename, buf.st_size);
	rc = ioctl(fd, FBIOGET_VSCREENINFO, &screeninfo);
	if (rc) {
		printf("Could not do ioctl. err: %d\n", errno);
		return errno;
	}	
	printf("%s: bits/pixel%d\n", filename, screeninfo.bits_per_pixel);
	len = screeninfo.xres * screeninfo.yres;
	fbuf = mmap(0, len, PROT_WRITE|PROT_READ, MAP_SHARED, fd, 0);
	if (fbuf == MAP_FAILED) {
		printf("Could not map: error: %d\n", errno);
		return errno;
	}
        if (argc > 1) {
		int outfd;
		outfd = open(argv[1], O_RDWR|O_CREAT, 0644);
		if (outfd != -1) {
			write(outfd, fbuf, len);
			close(outfd);
		}
	}
	printf("(%lx): Writting .. [%d:%d]\n", fbuf, screeninfo.xres,screeninfo.yres);
	i = 0;
	for (i = 0; i < len; i++) {
		fbuf[i] = (i % 255);
	}
	printf("Done!\n");
	if (munmap(fbuf, len)) {
		printf("Could not unmap: %d\n", errno);
		return errno;
	}
	close(fd);
	return 0;
}

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Frame buffer mmap not working in pvops dom0

[Pasi Kärkkäinen]

On Wed, Jul 21, 2010 at 10:42:09AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 21, 2010 at 05:16:13PM +0300, Pasi Kärkkäinen wrote:
> > On Wed, Jul 21, 2010 at 09:47:57AM -0400, Daniel De Graaf wrote:
> > > I'm trying to confirm the fix to the VESA fbdev mmap issue that was
> > > brought up a few months ago
> > > (http://marc.info/?l=xen-devel&m=126842551306571&w=2). The wiki page at
> 
> Weird. I don't remember seeing that e-mail..
> 
> > > http://wiki.xensource.com/xenwiki/XenPVOPSDRM says that this bug should
> > > be fixed, but doesn't point to a patch for the fix. I am still able to
> > > reproduce the issue both on real hardware and by running Xen under qemu
> > > (using cirrusfb on the dom0). Eamon (the original reporter) has also not
> > > been able to confirm a fix.
> > > 
> > > I'm currently testing using Xen 4.1 built from hg 21831:6bebaf40e925 and
> > > a pvops dom0 from xen/stable-2.6.32.x revid c0a00fbe.
> > > 
> > > So far, I've been able to determine that an mmap requesting multiple
> > > pages from /dev/fb0 will result in page table entries all pointing to
> > > the same physical page, which is not in the framebuffer address space.
> > > Writing to the mapped page ends up corrupting parts of kernel memory.
> > > I'd be happy to run further tests, try patches, or provide more
> > > information if needed.
> 
> Goodies. Let me fix up a tree that cleanly merges with Jeremy's xen/next
> (or xen/stable-2.6.32.x) and give you a go with that. And then from
> there we can come up with a fix.
> 

I'd prefer xen/stable-2.6.32.x, since that's what most people are using..
We'll get more testers that way.

-- Pasi

Re: Frame buffer mmap not working in pvops dom0

[Daniel De Graaf]

[-- Attachment #1: Type: text/plain, Size: 2728 bytes --]

On 07/21/2010 10:42 AM, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 21, 2010 at 05:16:13PM +0300, Pasi Kärkkäinen wrote:
>> On Wed, Jul 21, 2010 at 09:47:57AM -0400, Daniel De Graaf wrote:
>>> I'm trying to confirm the fix to the VESA fbdev mmap issue that was
>>> brought up a few months ago
>>> (http://marc.info/?l=xen-devel&m=126842551306571&w=2). The wiki page at
> 
> Weird. I don't remember seeing that e-mail..
> 
>>> http://wiki.xensource.com/xenwiki/XenPVOPSDRM says that this bug should
>>> be fixed, but doesn't point to a patch for the fix. I am still able to
>>> reproduce the issue both on real hardware and by running Xen under qemu
>>> (using cirrusfb on the dom0). Eamon (the original reporter) has also not
>>> been able to confirm a fix.
>>>
>>> I'm currently testing using Xen 4.1 built from hg 21831:6bebaf40e925 and
>>> a pvops dom0 from xen/stable-2.6.32.x revid c0a00fbe.
>>>
>>> So far, I've been able to determine that an mmap requesting multiple
>>> pages from /dev/fb0 will result in page table entries all pointing to
>>> the same physical page, which is not in the framebuffer address space.
>>> Writing to the mapped page ends up corrupting parts of kernel memory.
>>> I'd be happy to run further tests, try patches, or provide more
>>> information if needed.
> 
> Goodies. Let me fix up a tree that cleanly merges with Jeremy's xen/next
> (or xen/stable-2.6.32.x) and give you a go with that. And then from
> there we can come up with a fix.
> 
> Can you tell me how you came up with the analysis? (that should speed up
> finding the culprit). Any serial/dmesg outputs would be appreciated.
> 

I have been dumping the page tables (using the attached pt-dump script,
as qemu's "info tlb" only works on i386) from a paused qemu instance
that is running a simple mmap-and-spin program (also attached). All 100
pages map to physical memory address 39a4c000.

>From a bit more debugging, I've been able to trace the correct address
(0xf0000000) being lost when it is passed by xen_make_pte to
pte_pfn_to_mfn and eventually to get_phys_to_machine(0xf0000) which
returns -1. Still not sure where the final physical address is coming
from, but I'm guessing this is part of the problem.

> 
> Daniel,
> 
> I honestly don't remember which patch I thought fixed it. But I do know
> that when the /dev/fb0 was backed by DRM (nvidia) it worked (I used the 
> below program).
> 
> Granted now that I tested it with fbxine and it hangs with a Xen error.
> Let me start using Eamon's program.
> 

The attached program has no visible effect on the screen when run, so
it's likely also not working here.

-- 

Daniel De Graaf
National Security Agency

[-- Attachment #2: mmap-hold.c --]
[-- Type: text/plain, Size: 773 bytes --]

#include <sys/types.h>
#include <sys/mman.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>

static void bail(int cond, const char *msg)
{
	if (cond) {
		perror(msg);
		exit(1);
	}
}

#define COUNT 100

volatile int wobble;

int main(int argc, char** argv)
{
	int fd = open("/dev/fb0", O_RDWR);
	unsigned char *addr;
	wobble = 42;

	bail(fd < 0, "/dev/fb0");
	printf("Ready to map\n");

	if (argc == 1)
		while (wobble == 42);

	addr = mmap(NULL, 4096*COUNT, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
	printf("Mapped at %p\n", addr);
	bail(addr == MAP_FAILED, "mmap");
	int i,j=0;
	
	while (wobble != 42);
	// fault the pages in if they need to be
	for(i=0; i < COUNT; i++)
		j += addr[i*4096];
	
	while (wobble == 42);
}

[-- Attachment #3: pt-dump --]
[-- Type: text/plain, Size: 2864 bytes --]

#!/usr/bin/perl -w
#
# Page Table Dump of running process in qemu-x86_64
#
# Run on a stopped VM for reliable output
#
use strict;
use IO::Socket::UNIX;

die "Use: $0 unix-monitor [cr3]" unless @ARGV;

my $mon = IO::Socket::UNIX->new(Type => SOCK_STREAM, Peer => shift);

my $cr3;
if (@ARGV) {
	$cr3 = shift;
	print "Looking up page tables as if CR3=$cr3\n";
} else {
	print $mon "info registers\n";

	while (<$mon>) {
		m/^RIP=([0-9a-f]{16}) / and print "RIP=$1    ";
		m/ CR3=([0-9a-f]{16}) / and $cr3 = $1;
		last if / XMM15=/;
	}

	die unless defined $cr3;

	$cr3 = hex $cr3;

	printf "CR3=%016x\n", $cr3;
}

sub xp {
	my $ma = shift;
	my $res = sprintf "%016x: 0x([0-9a-f]+)", $ma;
	print $mon "xp $ma\n";
	while (<$mon>) {
		return hex $1 if /$res/;
	}
	die;
}

my $pml4 = $cr3 & 0xFFFFFFFFFFFFF000;

my($vstart, $pstart, $vcurr, $pcurr, $fcurr) = (1,0,1,0,0);

sub txpage {
	my($vaddr, $paddr, $psiz, $flags) = @_;
	if ($vaddr == $vcurr && $paddr == $pcurr && $flags == $fcurr)
	{
		$vcurr += $psiz;
		$pcurr += $psiz;
		return;
	}

	if ($vstart != 1) {
		my $len = $vcurr - $vstart;
		printf "   Translation: %16x -> %12x  %8x f=%012b\n", $vstart, $pstart, $len, $fcurr;
	}
	$vstart = $vcurr = $vaddr;
	$pstart = $pcurr = $paddr;
	$fcurr = $flags;
	$vcurr = $vaddr + $psiz;
	$pcurr = $paddr + $psiz;
}

for my $pml4i (0..0x1FF) {
	my $pml4e1 = xp $pml4 + $pml4i * 0x8;
	my $pml4e2 = xp $pml4 + $pml4i * 0x8 + 4;
	next unless $pml4e1 & 1;
	my $pdpt = (($pml4e2 << 32) | $pml4e1) & 0xFFFFFFFFF000;
	printf "Using PML4 entry    %03x             %12x           f=%012b\n", $pml4i << 3, $pdpt, $pml4e1 & 0xFFF;
	for my $pdpti (0..0x1FF) {
		my $pdpte1 = xp $pdpt + $pdpti * 0x8;
		my $pdpte2 = xp $pdpt + $pdpti * 0x8 + 4;
		next unless $pdpte1 & 1;
		if ($pdpte1 & 0x80) {
			print "TODO: 1GB page\n";
			next;
		}
		my $pd = (($pdpte2 << 32) | $pdpte1) & 0xFFFFFFFFF000;
		printf " Using PDPT entry     %03x           %12x           f=%012b\n", $pdpti << 2, $pd, $pdpte1 & 0xFFF;
		for my $pdi (0..0x1FF) {
			my $pde1 = xp $pd + $pdi * 0x8;
			my $pde2 = xp $pd + $pdi * 0x8 + 4;
			next unless $pde1 & 1;
			if ($pde1 & 0x80) {
				my $vaddr = ($pml4i << 39) | ($pdpti << 30) | ($pdi << 21);
				my $paddr = (($pde2 << 32) | $pde1) & 0xFFFFFFE00000;
				txpage $vaddr, $paddr, 0x200000, $pde1 & 0xFFF;
				next;
			}
			my $pt = (($pde2 << 32) | $pde1) & 0xFFFFFFFFF000;
			printf "  Using PD entry        %03x         %12x           f=%012b\n", $pdi << 1, $pt, $pde1 & 0xFFF;
			for my $pti (0..0x1FF) {
				my $pte1 = xp $pt + $pti * 0x8;
				my $pte2 = xp $pt + $pti * 0x8 + 4;
				next unless $pte1 & 1;
				my $vaddr = ($pml4i << 39) | ($pdpti << 30) | ($pdi << 21) | ($pti << 12);
				my $paddr = (($pte2 << 32) | $pte1) & 0xFFFFFFFFF000;
				txpage $vaddr, $paddr, 0x1000, $pde1 & 0xFFF;
			}
			txpage 1,1,1;
		}
		txpage 1,1,1;
	}
	txpage 1,1,1;
}

[-- Attachment #4: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Frame buffer mmap not working in pvops dom0

[Konrad Rzeszutek Wilk]

> I have been dumping the page tables (using the attached pt-dump script,
> as qemu's "info tlb" only works on i386) from a paused qemu instance
> that is running a simple mmap-and-spin program (also attached). All 100
> pages map to physical memory address 39a4c000.

The qemu output then isn't going to a VNC window but something else. I
presume the something else is the SDL piece? Were there any special flags
to enable this on QEMU?
> 
> >From a bit more debugging, I've been able to trace the correct address
> (0xf0000000) being lost when it is passed by xen_make_pte to
> pte_pfn_to_mfn and eventually to get_phys_to_machine(0xf0000) which
> returns -1. Still not sure where the final physical address is coming
> from, but I'm guessing this is part of the problem.

That looks like the VM_IO flag (_PAGE_IOMAP on the PTE) is not set somewhere.
Do you have an idea what piece of kernel code gets triggered when QEMU does
'mmap' on the /dev/fb0?

On my machine where I use KMS/DRM it ends up calling 'ttm_fb_mmap'. But
for your system, where it looks that you are using the "old" framebuffer
code it might be something entirely different.

.. snip..
> The attached program has no visible effect on the screen when run, so
> it's likely also not working here.

<nods> Looks quite similar to what I've been using.

Re: Frame buffer mmap not working in pvops dom0

[Konrad Rzeszutek Wilk]

> That looks like the VM_IO flag (_PAGE_IOMAP on the PTE) is not set somewhere.
> Do you have an idea what piece of kernel code gets triggered when QEMU does
> 'mmap' on the /dev/fb0?
> 
> On my machine where I use KMS/DRM it ends up calling 'ttm_fb_mmap'. But

err.. ttm_fbdev_mmap

Re: Frame buffer mmap not working in pvops dom0

[Daniel De Graaf]

On 07/21/2010 03:00 PM, Konrad Rzeszutek Wilk wrote:
>> I have been dumping the page tables (using the attached pt-dump script,
>> as qemu's "info tlb" only works on i386) from a paused qemu instance
>> that is running a simple mmap-and-spin program (also attached). All 100
>> pages map to physical memory address 39a4c000.
> 
> The qemu output then isn't going to a VNC window but something else. I
> presume the something else is the SDL piece? Were there any special flags
> to enable this on QEMU?

The exact command line I'm using is:

qemu-kvm -daemonize -usbdevice tablet -m 1024 \
	-monitor unix:fc13-mon,server,nowait \
        -net nic -net tap /dev/lvm0/FC13-64

This uses SDL graphics, which is qemu's default. Within qemu, I use
vga=ask on the xen command line in grub.

>> >From a bit more debugging, I've been able to trace the correct address
>> (0xf0000000) being lost when it is passed by xen_make_pte to
>> pte_pfn_to_mfn and eventually to get_phys_to_machine(0xf0000) which
>> returns -1. Still not sure where the final physical address is coming
>> from, but I'm guessing this is part of the problem.
> 
> That looks like the VM_IO flag (_PAGE_IOMAP on the PTE) is not set somewhere.
> Do you have an idea what piece of kernel code gets triggered when QEMU does
> 'mmap' on the /dev/fb0?
> 
> On my machine where I use KMS/DRM it ends up calling 'ttm_fb_mmap'. But
> for your system, where it looks that you are using the "old" framebuffer
> code it might be something entirely different.
> 

The code path is fb_mmap with a NULL fbops->fb_mmap, so it just
delegates to the default code. Specifically, io_remap_pfn_range is where
the bad mapping is requested.

I have a patch that fixes the issue, but I'm not sure under what
conditions the _PAGE_IOMAP bit needs to be set.

--- a/arch/x86/include/asm/fb.h
+++ b/arch/x86/include/asm/fb.h
@@ -10,6 +10,7 @@ static inline void fb_pgprotect
 {
        if (boot_cpu_data.x86 > 3)
                pgprot_val(vma->vm_page_prot) |= _PAGE_PCD;
+       pgprot_val(vma->vm_page_prot) |= _PAGE_IOMAP;
 }

 #ifdef CONFIG_X86_32

-- 

Daniel De Graaf
National Security Agency

Re: Frame buffer mmap not working in pvops dom0

[Konrad Rzeszutek Wilk]

> The code path is fb_mmap with a NULL fbops->fb_mmap, so it just
> delegates to the default code. Specifically, io_remap_pfn_range is where
> the bad mapping is requested.
> 
> I have a patch that fixes the issue, but I'm not sure under what
> conditions the _PAGE_IOMAP bit needs to be set.

Oh wow. That easy, eh?

> --- a/arch/x86/include/asm/fb.h
> +++ b/arch/x86/include/asm/fb.h
> @@ -10,6 +10,7 @@ static inline void fb_pgprotect
>  {
>         if (boot_cpu_data.x86 > 3)
>                 pgprot_val(vma->vm_page_prot) |= _PAGE_PCD;
> +       pgprot_val(vma->vm_page_prot) |= _PAGE_IOMAP;
>  }
> 
>  #ifdef CONFIG_X86_32


I would say this patch is more sensible as the VM_IO flag had been
set already, it just never got propagated:


diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 731fce6..187171b 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1362,6 +1362,7 @@ fb_mmap(struct file *file, struct vm_area_struct * vma)
 	vma->vm_pgoff = off >> PAGE_SHIFT;
 	/* This is an IO map - tell maydump to skip this VMA */
 	vma->vm_flags |= VM_IO | VM_RESERVED;
+	vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
 	fb_pgprotect(file, vma, off);
 	if (io_remap_pfn_range(vma, vma->vm_start, off >> PAGE_SHIFT,
 			     vma->vm_end - vma->vm_start, vma->vm_page_prot))


If that fixes your problem, are you OK with me sticking a Signed-off-by:
from you on this patch?

Re: Frame buffer mmap not working in pvops dom0

[Daniel De Graaf]

On 07/21/2010 03:50 PM, Konrad Rzeszutek Wilk wrote:
>> The code path is fb_mmap with a NULL fbops->fb_mmap, so it just
>> delegates to the default code. Specifically, io_remap_pfn_range is where
>> the bad mapping is requested.
>>
>> I have a patch that fixes the issue, but I'm not sure under what
>> conditions the _PAGE_IOMAP bit needs to be set.
> 
> Oh wow. That easy, eh?
> 
>> --- a/arch/x86/include/asm/fb.h
>> +++ b/arch/x86/include/asm/fb.h
>> @@ -10,6 +10,7 @@ static inline void fb_pgprotect
>>  {
>>         if (boot_cpu_data.x86 > 3)
>>                 pgprot_val(vma->vm_page_prot) |= _PAGE_PCD;
>> +       pgprot_val(vma->vm_page_prot) |= _PAGE_IOMAP;
>>  }
>>
>>  #ifdef CONFIG_X86_32
> 
> 
> I would say this patch is more sensible as the VM_IO flag had been
> set already, it just never got propagated:
> 
> 
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index 731fce6..187171b 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1362,6 +1362,7 @@ fb_mmap(struct file *file, struct vm_area_struct * vma)
>  	vma->vm_pgoff = off >> PAGE_SHIFT;
>  	/* This is an IO map - tell maydump to skip this VMA */
>  	vma->vm_flags |= VM_IO | VM_RESERVED;
> +	vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
>  	fb_pgprotect(file, vma, off);
>  	if (io_remap_pfn_range(vma, vma->vm_start, off >> PAGE_SHIFT,
>  			     vma->vm_end - vma->vm_start, vma->vm_page_prot))
> 
> 
> If that fixes your problem, are you OK with me sticking a Signed-off-by:
> from you on this patch?
> 

Yep, your version also fixes the problem, and I agree it's more
sensible. I'm OK with signing off on that patch.

-- 

Daniel De Graaf
National Security Agency

Re: Frame buffer mmap not working in pvops dom0

[Eamon Walsh]

On 07/21/2010 03:50 PM, Konrad Rzeszutek Wilk wrote:
>> The code path is fb_mmap with a NULL fbops->fb_mmap, so it just
>> delegates to the default code. Specifically, io_remap_pfn_range is where
>> the bad mapping is requested.
>>
>> I have a patch that fixes the issue, but I'm not sure under what
>> conditions the _PAGE_IOMAP bit needs to be set.
>>     
> Oh wow. That easy, eh?
>
>   
>> --- a/arch/x86/include/asm/fb.h
>> +++ b/arch/x86/include/asm/fb.h
>> @@ -10,6 +10,7 @@ static inline void fb_pgprotect
>>  {
>>         if (boot_cpu_data.x86 > 3)
>>                 pgprot_val(vma->vm_page_prot) |= _PAGE_PCD;
>> +       pgprot_val(vma->vm_page_prot) |= _PAGE_IOMAP;
>>  }
>>
>>  #ifdef CONFIG_X86_32
>>     
>
> I would say this patch is more sensible as the VM_IO flag had been
> set already, it just never got propagated:
>
>
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index 731fce6..187171b 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1362,6 +1362,7 @@ fb_mmap(struct file *file, struct vm_area_struct * vma)
>  	vma->vm_pgoff = off >> PAGE_SHIFT;
>  	/* This is an IO map - tell maydump to skip this VMA */
>  	vma->vm_flags |= VM_IO | VM_RESERVED;
> +	vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
>  	fb_pgprotect(file, vma, off);
>  	if (io_remap_pfn_range(vma, vma->vm_start, off >> PAGE_SHIFT,
>  			     vma->vm_end - vma->vm_start, vma->vm_page_prot))
>
>
> If that fixes your problem, are you OK with me sticking a Signed-off-by:
> from you on this patch?
>   


Either patch fixes the problem for me.

Tested-by: Eamon Walsh <ewalsh@tycho.nsa.gov>



-- 

Eamon Walsh 
National Security Agency

Re: Frame buffer mmap not working in pvops dom0

[Konrad Rzeszutek Wilk]

> > If that fixes your problem, are you OK with me sticking a Signed-off-by:
> > from you on this patch?
> > 
> 
> Yep, your version also fixes the problem, and I agree it's more
> sensible. I'm OK with signing off on that patch.

Oh, and here is the S-O-B that I missed sticking on the git tree.

Anyhow, I found out that his patch also fixes the Nvidia fb problem,
which is quite nice.

By any chance did you try to use Xserver on top of this patch? In the
past I had gotten this (from Xorg.0.log file):

==) Using config directory: "/etc/xorg.conf.d"
(XEN) mm.c:1747:d0 Bad L1 flags 400000
(XEN) mm.c:1747:d0 Bad L1 flags 400000
(XEN) mm.c:1747:d0 Bad L1 flags 400000
...
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument

.. and a continuing stream of FBIOPUTCMAP's.

Re: Frame buffer mmap not working in pvops dom0

[Konrad Rzeszutek Wilk]

> ==) Using config directory: "/etc/xorg.conf.d"
> (XEN) mm.c:1747:d0 Bad L1 flags 400000
> (XEN) mm.c:1747:d0 Bad L1 flags 400000
> (XEN) mm.c:1747:d0 Bad L1 flags 400000

With your patch, those messages above are gone.
> ...
> (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
> (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument

I get this even on baremetal, so I doubt this Xen problem. But 
I am curious how the fbdev works then under Xen fbdev device.
Or maybe it is a xorg-video-vesa it uses ...

Re: Frame buffer mmap not working in pvops dom0

[Daniel De Graaf]

On 07/28/2010 10:29 AM, Konrad Rzeszutek Wilk wrote:
>>> If that fixes your problem, are you OK with me sticking a Signed-off-by:
>>> from you on this patch?
>>>
>>
>> Yep, your version also fixes the problem, and I agree it's more
>> sensible. I'm OK with signing off on that patch.
> 
> Oh, and here is the S-O-B that I missed sticking on the git tree.
> 
> Anyhow, I found out that his patch also fixes the Nvidia fb problem,
> which is quite nice.
> 
> By any chance did you try to use Xserver on top of this patch? In the
> past I had gotten this (from Xorg.0.log file):
> 
> ==) Using config directory: "/etc/xorg.conf.d"
> (XEN) mm.c:1747:d0 Bad L1 flags 400000
> (XEN) mm.c:1747:d0 Bad L1 flags 400000
> (XEN) mm.c:1747:d0 Bad L1 flags 400000
> ...
> (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
> (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
> 
> .. and a continuing stream of FBIOPUTCMAP's.
> 

I had been testing using framebuffer only; I just tested Xorg, and it
appears to be working - I don't see any errors in my Xorg.0.log or on
the Xen console. Haven't tried running anything more interesting than
xterm, though.

I'm not certain if I've ended up testing the Xen fbdev device, or just
using the guest's i915 driver within the guest. This is with an empty
xorg.conf{,.d/}.

The only issue I've been having is that I haven't been able to get the
system to work more than once per powerup, even with a soft reboot of
the host (going back to the real BIOS). There's obviously some state not
being reset by the startup that is tripping it on later boots, but I
haven't yet been able to find out what it is.

-- 

Daniel De Graaf
National Security Agency