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

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

>-----Original Message-----
>From: Ian Pratt [mailto:m+Ian.Pratt@xxxxxxxxxxxx]
>Sent: Thursday, May 19, 2005 2:51 PM
>To: Tian, Kevin; Scott Parish; xen-devel@xxxxxxxxxxxxxxxxxxx
>
>
>
>> 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.
>
>Guests can have arbitrary sparse machine memory maps already on x86.
>
>Ian

So how does that sparse style get implemented? Could you say more or
show a link to the place in source tree? :)

Take following sequence in xc_linux_build.c as example:
1. Setup_guest() call xc_get_pfn_list(xc_handle, dom, page_array,
nr_pages), where page_array is acquired by walking domain->page_list in
HV. So page_array is actually the mapping of [index in page_list,
machine pfn], not [guest pfn, machine pfn].

2. loadelfimage() will utilize that page_array to load kernel of domU,
like:
pa = (phdr->p_paddr + done) - dsi->v_start;
va = xc_map_foreign_range(
        xch, dom, PAGE_SIZE, PROT_WRITE, parray[pa>>PAGE_SHIFT]);
Here parray[pa>>PAGE_SHIFT] is used, which tempt to consider index of
page_array as guest pfn, however it's not from explanation in 1st point.

Yes, it should work in above example, since usually kernel is loaded at
lower address which is far from I/O hole. So in lower range actually
"index in page_list" == "guest pfn". However this is not correct model
in generic concept. Especially for device model, which needs to map
whole machine pages of domU, also follows the wrong model as
xc_get_pfn_list + xc_map_foreign.

Maybe the sparse memory maps has already been managed inside HV as you
said, but we also need to waterfall same sparse info to CP and DM
especially for GB memory. That's why we're considering adding new
hypercall. 

Correct me if I misunderstand something there. :)

Thanks,
Kevin


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