[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [patch] more correct pfn_valid()

Context: x86_64, 6gig ram.

(XEN) Physical RAM map:
(XEN)  0000000000000000 - 000000000009dc00 (usable)
(XEN)  000000000009dc00 - 00000000000a0000 (reserved)
(XEN)  00000000000d0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000dff60000 (usable)
(XEN)  00000000dff60000 - 00000000dff72000 (ACPI data)
(XEN)  00000000dff72000 - 00000000dff80000 (ACPI NVS)
(XEN)  00000000dff80000 - 00000000e0000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec00400 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000fff80000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000180000000 (usable)    <---- above hole

Notice there is now memory above the pci hole.

get_page_from_l1e() has the following code:

        /* No reference counting for out-of-range I/O pages. */
        if ( !pfn_valid(mfn) )
            return 1;


   #define pfn_valid(_pfn)     ((_pfn) < max_page)

Since max_page is now above the out-of-range io, the pfn_valid()
returns "valid". And hence get_page() is called, but returns an
error given that the page count is zero ("not allocated") which
ultimately ends up that the ioremap() for several device drivers
fails with ENOMEM.

While attached patch fixes this problem (from empirical evidence),
there may be a better solution.


Scott Parish
Signed-off-by: srparish@xxxxxxxxxx

Attachment: pfn_valid.diff
Description: Text document

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.