>From: Isaku Yamahata
>Sent: 2006年3月10日 14:47
>
>Hi xen/ia64 developers.
>The attached patches for xen-ia64-unstable.hg are the incomplete
>patches
>of P2M/VP model take 2.
>With these patches dom0 boots and domU boots on vbd.
Good news and great work!
Several general comments for your reference first:
[SUBARCH]
Since you start to import more linux files with modifications, maybe
it's time now to consider make xenlinux/ia64 as a REAL subarch like x86/x86-64.
(agp.h, dma-mapping.h, io.h, machvec.h, page.h, etc.) Or we can call it a new
machvec on ia64, like a "xen" in same dir as "dig", "hp", etc. See what you've
done for CONFIG_XEN_IA64_DOM0_VP, which finally presents a new/virtual type of
IA64 box. By doing that, we back to same highway as x86, since subarch is
current way that xen community is supposing to linux community. Also you see
how it makes your later work cleaner, though a bit extra effort may be required
to setup the initial hierarchy.
[DOMMEM ALLOCATION]
Decision for whether allocate-on-demand policy earlier. From set of
patches of your work, bunch of code is added to handle allocate-on-demand
property of current xen/ia64 domain, both in xen and xenlinux. We may need to
evaluate earlier whether it's still worthy of keep there, since your changes
also modify x86 code and effort is required to convince. Once it's accepted by
x86, there'll be another story if people finally chooses another way.
One reason for that policy is lack of balloon support in early stage,
and thus allocate-on-demand can partly accommodate situation. Normally we want
allocate-on-demand to present more than physical existing resources (like
paging). However currently there's no code to handle failure allocation when
multiple ia64 domains run a long time with total phys_mem>mach_mem. Then
allocate-on-demand is meaningless and only show worse performance compared to
allocate-all-at-creation with the latter to reduce your patch size a lot for
better acceptance.
So based on support of balloon feature, we can adopt the
allocate-all-at-creation model like x86 in xc_linux_build.c, and later let
balloon driver to handle the resource transfer among domains. That can also
help bunch of code differences within xen, which is a trouble in many places.
(But yes, this will add another huge effort for cleanup:-)
[HYPERCALL for new do_dom0vp_op]
I noted that you added a bunch of new interfaces to do some specific
dom0 operations for phys2mach relationship. (Not looked into yet) But seems
some ops are conflicting to common code, like IA64_DOM0VP_populate_physmap when
there is XENMEM_populate_physmap. Any reason there?
Another example like XENMEM_translate_gpfn_list. Is it possible to be
used in your patch?
Do you have idea how much effort would be added if direct map p2m table
into dom0? More or less, compared to hypercall approach?
That's it for now. :-)
Thanks,
Kevin
>The following 10 patches are for dom0 P2M/VP model.
>9178:aa065d3355fc_move_linux_efi_h_to_linux_xen_linux_efi_h.patch
>9179:6bf3f1ec390e_dom0_vp_model_xen_side_README_orig_efi_h.p
>atch
>9180:186213411d3d_dom0_vp_model_xen_part.patch
Dom0_ops
>9181:d131d962bc5a_import_io_h.patch
>9182:9d4e0ae38ca7_import_page_h.patch
>9183:6fe7bb6c4de9_import_pgalloc_h.patch
>9184:82b7dd86574f_import_dma_mapping_h.patch
>9185:0f6217859560_import_machvec_h.patch
>9186:1f917475f4a6_import_agp_h.patch
>9187:b4817059e252_dom0_vp_model_linux_part.patch
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home