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
|
Home