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

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

>From: Isaku Yamahata
>Sent: 2006年3月10日 14:47
>
>The following 9 patches are for grant table and vbd.
>9188:f1f79363e36d_libxc_ia64_get_pfn_list_work_around.patch
>9189:a60e1b202538_dont_use_vga_area.patch
>9190:34adabc2b3b0_gnttab_shared_gmfn.patch
>9191:2ac9130fb9f6_fix_grant_entry_t_frame.patch

This one is a fix and can be sent out to xen mailing list earlier. But it may 
not be so urgent to see the issue for IA64 and x86-64. See how large 
even 32bit can support: 4G * 4K = 16T. I don't think people ever tested on 
it now. :-)

>9192:80353e9e2e0f_grant_table_xen_part.patch
>9193:6922c2fe7446_grant_table_linux_part.patch

Sorry that I didn't look into carefully, but why following logic:
+#ifndef __ia64__
        shared[ref].frame = frame;
+#else
+       shared[ref].frame = mfn_to_pfn(frame);//XXX
+#endif

The caller already does virt_to_mfn which results a hypercall by your 
model, and now another hypercall caused by mfn_to_pfn again. It's better 
to make a decision whether frames passed from xenlinux is 
pseudophysical or machine, and then just support it uniformly. You see 
current grant table code can handle either case, differentiated by shadow 
translated mode for x86. Though we have no shadow code for xen/ia64, 
but that's the flag you can use to simplify changes.

BTW, what's the intent of alloc_vm_area? Seems no one calls it. Also a 
typo there:
struct vm_struct* area;
...
area = kmalloc(sizeof(area), GFP_KERNEL); which only gives you 8
bytes. :-)

Thanks,
Kevin

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