WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

RE: [Xen-ia64-devel] [PATCH] [RFC] [TAKE2] P2M/VP (incomplete) patches

To: "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] [PATCH] [RFC] [TAKE2] P2M/VP (incomplete) patches
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Tue, 14 Mar 2006 00:02:04 +0800
Delivery-date: Mon, 13 Mar 2006 16:02:55 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZEDuR8koNWtvbIRv2wlYMRV0tx9QCl+/zA
Thread-topic: [Xen-ia64-devel] [PATCH] [RFC] [TAKE2] P2M/VP (incomplete) patches
>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