Re: [Xen-devel] Re: mm.c:777:d2 Non-privileged (2) attempt to map I/O space 000f995a + (XEN) mm.c:845:d20 Error getting mfn jd (pfn 84fd) from L1 entry 800000000246d467 for l1e_owner=20, pg_owner=32753

[Markus Armbruster <armbru@xxxxxxxxxx>]

Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> writes:

>> (XEN) mm.c:841:d5 Error getting mfn 7c1b3 (pfn 784e1) from L1 entry 
>> 800000007c1b3467 for l1e_owner=5, pg_owner=32753
>> which also loops around forever.
>> 
>
> Jeremy, Keir, Ian, Jan, et. al.:
>
> If you set vfb=['type=vnc,vnclisten=0.0.0.0,vncunused=1']
> for your pv-ops domU you get:
> (XEN) mm.c:845:d20 Error getting mfn jd (pfn 84fd) from L1 entry 
> 800000000246d467 for l1e_owner=20, pg_owner=32753
> this is the first attempt at the fix.
>
> What essentially happens is the Plymoth (a framebuffer daemon) starts
> writing to the frame buffer, causes a page fault and the domU kernel doesn't 
> handle
> it too well.
>
> Specifically these are the steps:
> user space:
>  fd = opens("/dev/fb0");
>  handle =mmap(0, len, PROT_WRITE, MAP_SHARED, fd, 0)
>
> and in the kernel the fb_deferred_io_mmap is called which
> sets:
>  vma->vm_flags = (VM_DONTEXPAND | VM_RESERVED | VM_IO)
>
>  [VM_IO means that subsequent pages will have PAGE_IOMAP set]
>
> next in the user space we do:
>  handle[i] = 'a';
>
> which causes a page_fault and we jump to the kernel:
> page_fault ->
>       handle_mm_fault ->
>               __do_fault()
>                   |-----vm_ops->fault (fb_deferred_io_fault):
>                   |           fb_deferred_io_page:
>                   |                   vmalloc_to_page [We now have a page]
>                   |           vmf->page = page [page attached to the user 
> address, good]
>                     |----mk_pte( .. ), sets PAGE_IOMAP
>                     |
>                     |----xen_set_pte_at ():
>                       [ This is the fun part ]
>                         |----if (xen_iomap_pte(pteval)) [ checks if 
> _PAGE_IOMAP is set]
>                                   |----xen_set_domain_pte():
>                                       [which makes the PTE belong to DOMID_IO]
>
> And at that point the Xen Hypervisor is called, and spits out:
> (XEN) mm.c:845:d20 Error getting mfn jd (pfn 84fd) from L1 entry 
> 800000000246d467 for l1e_owner=20, pg_owner=32753
>
> as it interprets the PFN as the MFN.
>
> This is incorrect as the page is vmalloc-ed and has no IO backing.
>
> Poking around I've come up with three ideas to solve this:
>
> 1). Inhibit xen_fb_deferred_io_map from setting VM_IO. That fixes the issue, 
> but
>     there are drivers (sh_mobile_lcdcfb.c) that have the fb be backed up by a 
> physical
>     page, in which case VM_IO is correct. So this is a no go.
>
> 2). Inhibit xen_set_pte_at to call xen_set_domain_pte if the page has 
> _PAGE_USER and _PAGE_IOMAP.
>     That did not work at all. The Hypervisor seemed to have lost any clue to 
> whom the page belongs.
>
> 3). Make xen-fbfront implement its own mmap functionality. This is what 
> linux-2.6.18.hg has.
>     I made an attempt at back-porting it (thought it is quite interrupt heavy 
> as each
>     page_fault causes it to trigger a HYPERVISOR event channel up call). I 
> will need to redo
>     this if this seems to be the right way.

I recommend against 3).

2.6.18's xenfb doesn't rely on deferred I/O, because that didn't exist
then.  It rolls its own code to do pretty much the same.  The code is
hairy (it took us a few iterations to get it working reliably), and
there's still a race left in it[*].  It makes much more sense to solve
such a hairy problem in just one place (fb_defio.c), and make that
sufficiently capable for all uses.  Moreover, I'd wager that in-tree
fb_defio.c has been reviewed much more thoroughly than the out-of-tree
2.6.18 xenfb.c.

> Thoughts? Maybe there is a better way at doing this?
>
> Attached is the test-case, and the patch for 3). Patch inlined for easier 
> view:
[...]

[*] https://bugzilla.redhat.com/show_bug.cgi?id=219787

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