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

[Scott Parish <srparish@xxxxxxxxxx>]

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;

where:

   #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.

sRp

-- 
Scott Parish
Signed-off-by: srparish@xxxxxxxxxx

pfn_valid.diff
Description: Text document

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