[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |