>> 3. I'm not sure why latest check-in about DOM0_GETMEMLIST differs
much
>> from x86 behavior. Could you explain a bit about that? IMHO, XEN/IA64
>> can have same syntax as x86 easily, since page allocator already
>> aggregates available pages list under domain struct. So a different
>> version is provided enclosed by CONFIG_VTI. If we can set on the same
>> page later, it may be extracted out then.
>
>This is my code so I'll explain. I don't have a particular attachment
>to this solution, I'm happy to discuss it.
>
>My first issue with the x86 DOM0_GETMEMLIST is that it looks at the
>_allocated_ list. This could interfere with use of alloc_domheap_pages
>in the hypervisor, as the user's call to DOM0_GETMEMLIST may include
any
>pages that have been allocated by the hypervisor from the domain's
heap.
>I notice for instance that your VMMU code uses alloc_domheap_pages.
If domain pointer passed to alloc_domheap_pages is NULL, that page won't
be bound to any domain. Only the request with specific domain pointer
will go to active page_list of that domain. VMMU allocates from domain
heap with 1st parameter as NULL, so those system pages are aside from
pool queried by DOM0_GETMEMLIST.
>
>The other issue is that the pages need to be added to the target
>domain's mfn/pfn mapping. I was trying to avoid adding more
>IA64-specific hypercalls by doing the allocation and mapping within
>DOM0_GETMEMLIST. Perhaps you can say more about your userspace
>implementation (i.e. xc_linux_build or equivalent). How do you map
>the pages into the target domain's physical address space?
A simplified flow of control panel is:
1. DOM0_DO_CREATEDOMAIN to create housekeeping structures within HV
2. DOM_MEM_OP to allocate configured memory to specified domain.
Note: In this step, all required machine pages have already been
allocated and linked under page_list of that domain.
3. DOM0_GET_MEMLIST to get active page list of domain to be constructed
Note: No newly allocation should happen within this hypercall,
which just aims to get list from step 2.
4. Then CP will manipulate domain's memory based on info from step3.
So if you follow the same sequence of CP (should be), you'll find no
actual difference between IA64 and x86 at all. Hope answers your
concern. ;-)
Control panel will map target domain's physical space into its own
virtual space, based on page list acquired from step 3. As Ian said,
para-virtualized x86 domain has a physically contiguous memory layout,
without any memory hole and I/O range inside. (Front end/Back end
eliminates requirement for I/O range). So the index of the page list
actually can be considered as physical pfn of target domain. Then that
array is actually a guest pfn->machine pfn mapping table, and then CP
can use xc_map_foreign to map them directly. However for unmodified
domain, we have to present a real-platform-like memory layout, including
low MMIO, IPI base, etc. So we introduce a new hypercall,
DOM0_GET_SECTIONINFO, to get the memory layout early before invoking
DOM0_GET_MEMINFO. Then the two together provide vti builder enough info
to work correctly.
If para-virtulization on IA64 follows exactly as x86, you don't need
that new hypercall. Or else, you see its effect as above. :)
Thanks,
Kevin
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home