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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Ian Pratt
>Sent: Thursday, May 19, 2005 6:18 AM
>
>>    #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.
>
>I think the best fix is to have the frame_table cover the whole of
>physical ram, and then mark non-ram pages in the frame_table.
>
>To save some memory, we could map the frame_table in virtual address
>space, then use __get_user when reading from it (a fault indicates a
>non-ram page too)
>
>Best,
>Ian
>

Agree with the approach for virtual frame_table to support big hole,
just like virtual memmap in Linux working currently on large machine.
However this one actually throws a brick about how to support large hole
of DomU.

Frame table itself only describes machine hierarchy, and same problem
also exists for PMT (or 1:1 page table) which describes the hierarch in
guest physical layer to DomU. With more deployments of xen and with more
hardware resources, it's reasonable to configure DomU with GB memory
which also covers big I/O hole in guest physical layer. Say providing 4G
to DomU, the PMT table has to cover whole 5G space if I/O hole is 1G.
This problem is especially practical on platform with big address space,
like x86/64 and IPF.

We realized this problem in progress of design and implementation for
supporting DomU on IPF/VTI. Actually current work model in control panel
and device model is somehow not matching above requirement. Usually the
sequence in CP or DM is to call xc_get_pfn_list and then extract guest
pfn -> mfn mapping info in a plain array, and later use xc_map_foreign
to map domU's space into Dom0's virtual space based upon that plain
array. The major problem is:
        - Currently xc_get_pfn_list is implemented in HV by walk
domain->page_list, however page_list is only collection of machine
page_frames allocated to this domain which doesn't reflect accurate
guest pfn -> machine pfn relationship
        - DM or CP shouldn't assume a plain continuous memory mapping

To solve this issue, we're considering following approaches:
        1. Add a new DOM0_GETMEMSECTIONS hypercall to get holes first,
and then use xc_get_pfn_list to get pure memory mapping. Finally these
info can be passed into xc_map_foreign to construct mapping in Dom0's
virtual space.

        2. Add a new DOM0_GETPMTTABLE, which returns a plain array
including those holes. Then without change to xc_map_foreign which
simply also includes holes upon that array.

Comments?

Rgs,
Kevin

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