This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: mm.c:777:d2 Non-privileged (2) attempt to map I/O sp

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: 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
From: Markus Armbruster <armbru@xxxxxxxxxx>
Date: Tue, 01 Dec 2009 10:26:21 +0100
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, JBeulich@xxxxxxxxxx, Ian.Campbell@xxxxxxxxxxxxx, Olivier NOEL <ONOEL@xxxxxxxxxxxxxx>, keir.fraser@xxxxxxxxxxxxx
Delivery-date: Tue, 01 Dec 2009 01:26:50 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20091201031120.GA11230@xxxxxxxxxxxxxxxxxxx> (Konrad Rzeszutek Wilk's message of "Mon, 30 Nov 2009 22:11:20 -0500")
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <481249.38422.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <4A78CA69.3090105@xxxxxxxx> <0E87C0E865217944860BB378D2898000E1467F@xxxxxxxxxxxxxxxxxx> <0E87C0E865217944860BB378D2898000E146B1@xxxxxxxxxxxxxxxxxx> <4A7B306D.5080108@xxxxxxxx> <20091109235051.GA20408@xxxxxxxxxxxxxxxxxxx> <20091201031120.GA11230@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
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=,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 
>     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

<Prev in Thread] Current Thread [Next in Thread>